[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

> 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?


`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: