Re: Shared library defines a RPATH
On Sun, Jul 28, 2002 at 10:01:31AM -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 28 Jul 2002, Marcus Brinkmann wrote:
> > ld.so.conf is a Linuxism, and not part of the ELF standard.
>
> Yes. But Debian *is* Linux-tainted. If we're going to fix this, we will
> need to add something like ld.so.conf to the other dynamic loaders, or fix
> the problems rpath introduce IMHO. It makes no sense to go back to what we
> know to be a bad, fundamentaly broken idea.
My point was not really to argue the current situation. I realize the
problem that rpath causes (although, really, rpath is not the only reason
for software not being relocatable), and I realize that there is no proper
fix with the version of the ELF standard in use by our tools.
What I wanted to say is that rpath is the tool that is given to us in the
present situation, and that the upcoming ELF standard is going to provide us
with a better tool, runpath.
> * rpath breaks major lib upgrades such as the libc5 -> libc6.
Uh, well, the way that we managed this upgrade was particularly unorthodox and
non-standard. You can not blame rpath that it doesn't play along nicely
with whatever dirty hacks you put into your runtime linker to automatically
sort out incompatible inter-library dependencies.
Again, please let me state that I know that the ELF standard doesn't give us
a proper way to handle the transition from libc5 -> libc6 gracefully. There
simply is no way to express the incompatibility in inter-library dependencies.
But this time it really is not rpath's fault.
> > Now, the criticism that this is not relocatable is valid, and that's why the
> > current version of the ELF standard is introducing runpath, which has the
> > same semantics has rpath but has a lower precedence then LD_LIBRARY_PATH.
> > This should make everyone happy. It is already supported by the GNU libc
> > runtime linker, but unfortunately binutils+gcc can not add the runpath to
> > the object files yet. :-/ I guess as soon as all GNU tools support it,
> > it will be used by libtool instead of rpath.
>
> Maybe it will be enough. It *has* to have lower precedence than
> _everything_ else, though. This includes even the standard linker
> directories (ld.so.conf in Linux), otherwise it is as bad as rpath was...
ld.so.conf is not part of any standard. So obviously the standard that
specifies runpath doesn't say anything about the precedence of ld.so.conf
compared to runpath. This is a question the maintainer of the runtime linker
used in GNU/Linux has to decide.
And no, I don't agree with what you say. The problem with rpath is that it
can not be overridden at all. Now you say it would be a problem if runpath
would override anything. Why do you think so?
> If it has lower precedence than everything else, I certainly would have no
> qualms about using it in Debian, heck, I would welcome it with open arms :)
Well, I think you will be happy. I don't really know the order of
precedence by heart, but it can be overridden (at least by LD_LIBRARY_PATH),
and I think it should be ok.
I would like to give more information, but large parts of the network are
currently inaccessible for me [and this includes google] :(
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org marcus@gnu.org
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: