Re: [rfc] keep LD_LIBRARY_PATH from tromping on libtool wrapped files
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
Re: [rfc] keep LD_LIBRARY_PATH from tromping on libtool wrapped files
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 ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
[rfc] keep LD_LIBRARY_PATH from tromping on libtool wrapped files
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
--- monkey/ltmain.in
+++ butt/ltmain.in
@@ -5085,6 +5085,11 @@
$echo >> $output "\
if test \"\$libtool_execute_magic\" != \"$magic\"; then
# Run the actual program with our arguments.
+
+ # Make sure env LD_LIBRARY_PATH does not mess us up
+ if test -n \"\${LD_LIBRARY_PATH+set}\"; then
+export LD_LIBRARY_PATH=\$progdir:\$LD_LIBRARY_PATH
+ fi
"
case $host in
# Backslashes separate directories on plain windows
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem:cannot build libtool
Hi Sharad, Please keep the mailing list copied, thank you. * sharad wrote on Wed, Sep 14, 2005 at 02:44:22PM CEST: > > From: "Ralf Wildenhues" <[EMAIL PROTECTED]> > > * sharad wrote on Wed, Sep 14, 2005 at 01:16:40PM CEST: > > > > > > I've cross-compiled RPM (red hat package manager) using > > > mipsel-linux-gcc.The compilation seems to be OK with some > > > warnings.But at the end of compilation following error shoots up: > The libtool version is libtool-1.4.3-5. That's pretty old. You should try updating it, but it may not be trivial in this case. You could also ask the maintainers to use a more recent Libtool. > Also the configuration was like > > ./configure --prefix=/home/sharad/rpm2/rpm-4.1/rpmmips --host = mips32 > CC=mipsel-linux-gcc CXX=mipsel-linux-gcc. Most likely you should have used just ./configure --prefix=/home/sharad/rpm2/rpm-4.1/rpmmips --host=mipsel-linux Then the configure script should find the correct $CC and $CXX itself, I believe. > It created the makefile in rpm directory with correct options but did not > reflect in other directories having depencies like db3,python. So i had to > manually change each makefile in the subdirectories for CC,CXX,AR and RANLIB > option. Hmm. I can't say anything about this; that's probably due to RPM using old versions of Autoconf (and possibly Automake) as well. Most likely the RPM maintainers can help you more. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem:cannot build libtool
Hi Sharad, * sharad wrote on Wed, Sep 14, 2005 at 01:16:40PM CEST: > Hi everyone, > I've cross-compiled RPM (red hat package manager) using > mipsel-linux-gcc.The compilation seems to be OK with some > warnings.But at the end of compilation following error shoots up: > > libtool: link: cannot build libtool library `librpmdb.la' from non-libtool > objects on this host: mut_pthread.o client.o db_server_clnt.o db_server_xdr.o > gen_client.o. > > What can be the cause and solution for this. Please show how you actually configured RPM, and the output of configure. Also please show ./libtool --version Note that the current stable version is 1.5.20, and anything earlier than 1.5.16 will have serious deficiencies with respect to $host_alias prefixes. So if RPM was libtoolized with an older version, you should update that first (rerun 1.5.20 libtoolize and take care that it finds the macros from 1.5.20 libtool.m4). Still, unfortunately, cross compiling glitches may remain, but not the one you are seeing now. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool problem:cannot build libtool
Hi everyone, I've cross-compiled RPM (red hat package manager) using mipsel-linux-gcc.The compilation seems to be OK with some warnings.But at the end of compilation following error shoots up: libtool: link: cannot build libtool library `librpmdb.la' from non-libtool objects on this host: mut_pthread.o client.o db_server_clnt.o db_server_xdr.o gen_client.o. What can be the cause and solution for this. Can any one help me please,Thanks in advance. Thnx/Rgds Sharad ___ http://lists.gnu.org/mailman/listinfo/libtool
