Re: [rfc] keep LD_LIBRARY_PATH from tromping on libtool wrapped files

[Mike Frysinger]

On Wednesday 14 September 2005 11:36 pm, Albert Chin wrote:
> On Wed, Sep 14, 2005 at 08:32:12PM -0400, Mike Frysinger wrote:
> > normally this is no problem for libtool ... it installs a wrapper in
> > src/file which runs src/.libs/lt-file which is compiled with RUNPATH tags
> > so that the libmagic.so.1 in src/.libs/ is used.  the trouble is when the
> > user has LD_LIBRARY_PATH set such that it points to the older
> > libmagic.so.1.  if the system library loader searches LD_LIBRARY_PATH
> > before RUNPATH elf tags, the older libmagic.so.1 will be loaded instead
> > of the one which has the newer functionality.  the new file tries to use
> > that functionality and the whole process fails.  for example, the dynamic
> > loader from glibc respects LD_LIBRARY_PATH before elf RUNPATH tags.
> >
> > ive attached a patch against libtool-1.5.20 which checks to see if
> > LD_LIBRARY_PATH is set, and if it is, will add the .libs dir to the head
> > of the searchpath.  i have a passing familiarity with libtool internals
> > so i doubt this patch is perfect, but i'd like feedback/comments/etc...
> > from people who know more than i ;)
>
> This seems to be a workaround for a user-generated problem.

i agree the example i used was based on a user generated problem and that it 
is kind of stupid for them to be exporting LD_LIBRARY_PATH to be pointing at 
system paths, but i'm not so sure that libtool shouldnt protect against it 
(hence the 'rfc' rather than 'this is a bug').

i could see something not too unlikely like a local user compiling and 
installing programs in a local prefix in their $HOME if they lack real admin 
access.  simply exporting LD_LIBRARY_PATH is a bit easier than 
knowing/understanding how to use RUNPATH elf tags ... under this scenario, 
they too would hit the issue of the wrong libmagic.so.1 being loaded and the 
build going boom.

> If gcc/ld 
> was used to build the new 'file' program, they would have the same
> error as that generated by libtool. Shouldn't libtool then try to
> mimic this behavior, not "correct" it?

not sure what you mean by this.  the wrapped 'file' program (src/file) is a 
libtool script whose purpose is to make sure that you can execute the wrapped 
program until all dependent libraries are installed into the normal library 
search path.  since libtool already goes to lengths to make sure that the 
wrapped program finds and uses the local build libraries (src/.libs/), why 
not this one more sanity check ?
-mike