Re: Shared library defines a RPATH
On Sun, 28 Jul 2002, Marcus Brinkmann wrote:
> 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.
Well, we agree on that.
> > * 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
Do tell. But it worked, and there were not better solutions at the time (and
I don't know of any others now, either...)
> > 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.
This makes a lot of sense. I hope runpath becomes semantically the same as
a LD_LIBRARY_PATH (with lower precedence than LD_LIBRARY_PATH), that is
enforced for setuid and setgid binaries... I think that would be enough.
> 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?
Well, the problem we face is actually adding 'default' locations for
libraries within a very narrow scope: a single lib, or app. At least in
Debian (I do realise it is not what an user or local admin would be trying
to do).
We want to be able to tell the linker to somehow look for the library in a
certain place, because that is the default location for that library. We
are not trying to tell it to read it from there no matter what -- that's
what rpath does.
If runpath has the lowest possible priority (LD_LIBRARY_PATH being the
highest for non-setuid/setgid binaries, followed by rpath, then by the
default search directories for the linker (which are often searched in a
deterministic way, and therefore priority-ordered), and only then runpath),
it is not going to break any possible games we might have to play with the
linker. So, it is desirable to have it at the lowest priority (because that
would be enough to fix the problem Debian has, anyway).
> 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.
Nice to know that.
> I would like to give more information, but large parts of the network are
> currently inaccessible for me [and this includes google] :(
No problem, Marcus. You have already eased my doubts about runpath.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: