This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: RPATH overriding
> From: Ulrich Drepper <drepper@cygnus.com>
> Date: 18 May 1998 16:10:45 -0700
> > > Anybody having more possibilities? Any preferences?
> >
> > You could add a variable that is an "override" search path used before all
> > else.
>
> Hhm, I do not really like this super-variable idea. It might help
> here put disturb us in another situation. LD_BLACKLIST or so would be
> a pinpoint solution. But please convince me.
Here's a case when I would have liked something like this:
The libtool package uses RPATH for _everything_ [IMHO, this is a
mistake]. A few weeks ago, I found a bug in binutils, and recompiled
it with an added printf() to help me track it down. It took me almost
half an hour to realise that the reason I wasn't getting any debugging
output was because, despite its claims, the libtool 'ld-new' script was
still getting libbfd from /usr/lib, because of the RPATH. I had to
re-link by hand without the -rpath option, which seems to defeat the
purpose of using libtool.
[It didn't help that the bug was preventing me from just running gdb
on the linker :-( ].
My preference would be an environment variable 'LD_IGNORE_RPATH',
containing the names of shared libraries ('libfoo.so', not
'/usr/lib/libfoo.so', and matched by strncmp() or similar so that
people don't have to work out that libfoo.so.33 actually has a
soname of libfoo.so.26). It would be the user's responsibility to
make sure that this doesn't cause trouble.
--
Geoff Keating <Geoff.Keating@anu.edu.au>