Re: Shared library defines a RPATH
On Sun, Jul 28, 2002 at 10:40:51AM -0300, Henrique de Moraes Holschuh wrote:
> > > * 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...)
There is no solution that I know of (and I talked to Roland McGrath about
it, who wrote the GNU linker).
> > 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).
I think the generic problem is to have libraries in a non-standard place,
without regards to how many programs use them. For example, /usr/X11R6/lib
is already such a non-standard place, but I don't know if that has a narrow
scope in your eyes :)
> 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.
Yup.
> If runpath has the lowest possible priority (LD_LIBRARY_PATH being the
> highest for non-setuid/setgid binaries, followed by rpath,
I am confused, because we already know that rpath always has the highest
priority, and this won't be changed for backward compatibility (that's why a
new property, runpath, had to be introduced).
> 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).
I don't think the order of standard directories and runpath matters,
because runpath is only used for non-standard directories, so usually the
two sets would be distinct :) An issue might arise if you move a library,
but if you really move it, it is only in one place either way, and that's
ok, then, too.
I do remember that LD_LIBRARY_PATH overrides runpath. I don't remember
if runpath is searched before or after standard places, sorry (and google is
still disconnected from me). Maybe somebody else can check?
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: