libtool
[Top][All Lists]
Advanced

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

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


From: Albert Chin
Subject: Re: [rfc] keep LD_LIBRARY_PATH from tromping on libtool wrapped files
Date: Wed, 14 Sep 2005 22:36:42 -0500
User-agent: Mutt/1.5.6i

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

Setting LD_LIBRARY_PATH to one of the default search paths is just
wrong anyway.

-- 
albert chin (address@hidden)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]