[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[rfc] keep LD_LIBRARY_PATH from tromping on libtool wrapped files
From: |
Mike Frysinger |
Subject: |
[rfc] keep LD_LIBRARY_PATH from tromping on libtool wrapped files |
Date: |
Wed, 14 Sep 2005 20:32:12 -0400 |
User-agent: |
KMail/1.8.2 |
a build issue came up in Gentoo when people attempted to upgrade from
file-4.12 to file-4.15. the issue was tracked back to users having
LD_LIBRARY_PATH set in their env and was causing the wrong library to be
loaded. this e-mail isnt about whether users should be screwing around with
LD_LIBRARY_PATH, but whether libtool should make sure it doesnt screw it up.
the build process of file includes:
- building libmagic.so
- building the file binary
- compiling the mime source files using the freshly generated file binary
if the build system has say file-4.12 installed, it has `file` in $PATH and
libmagic.so.1 in the normal library search path. when you compile a newer
version of file, say 4.15, it will use the freshly built file to compile the
mime sources. in order to do this, it needs functions from libmagic. since
the ABI is forward compatible, both file-4.12 and file-4.15 use
libmagic.so.1. if the mime sources require newer functionality, the file
binary will have to load the newer libmagic.so.1 instead of the already
installed libmagic.so.1.
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 ;)
so to review the issue in nice bullet form:
- install file-4.12
- export LD_LIBRARY_PATH to wherever libmagic.so.1 has been installed
- try to compile file-4.15
- watch build fail because libmagic.so.1 from file-4.12 was used instead of
libmagic.so.1 from file-4.15
-mike
libtool-1.5.20-override-LD_LIBRARY_PATH.patch
Description: Text Data
- [rfc] keep LD_LIBRARY_PATH from tromping on libtool wrapped files,
Mike Frysinger <=