This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]