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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
