The problem happens with ltmain.sh generated wrappers around executables. That is, the wrapper which libtool will create around applications before they're installed. This is quite useful to be able to test programs without having to install them, we use this extensively in GStreamer for example. The problem is that ... those wrappers insist on setting the following LD_LIBRARY_PATH before calling the target application (.libs/<appname>): LD_LIBRARY_PATH="/usr/lib:/usr/lib64:/home/bilboed/work/devel/gst-plugins-base/gst-libs/gst/interfaces/.libs:$LD_LIBRARY_PATH" the original Makefile.am specifies the following : LDADD = $(GST_LIBS) $(GTK_LIBS) $(top_builddir)/gst-libs/gst/interfaces/libgstinterfaces-@GST_MAJORMINOR@.la The expected LD_LIBRARY_PATH should be : LD_LIBRARY_PATH="/home/bilboed/work/devel/gst-plugins-base/gst-libs/gst/interfaces/.libs:$LD_LIBRARY_PATH" that is : <specified paths>:<currently overloaded paths> followed by the implicit system paths (which one doesn't have to specify). I tried applying all the patches from debian-experimental, but none of those fix this issue. When comparing the libtool which libtoolize generates on karmik and gentoo (after applying karmik patches) I see the following main differences: @@ -61,7 +61,7 @@ pic_mode=default # Whether or not to optimize for fast installation. -fast_install=needless +fast_install=yes # The host system. host_alias= @@ -211,7 +211,7 @@ shlibpath_var=LD_LIBRARY_PATH # Is shlibpath searched before the hard-coded library search path? -shlibpath_overrides_runpath=yes +shlibpath_overrides_runpath=no # Format of library name prefix. libname_spec="lib\$name" When setting those two variables to what karmik uses... the problem goes away and the wrapper uses the expected library paths. The real question is therefore... why does libtoolize creates a libtool with those variables set differently ?
what you want to do is completely the opposite of fast-install (which is what you're changing in libtool). sounds like libtool is doing what you're telling it to -- change the order of LDADD and the order of paths added to LD_LIBRARY_PATH will change. convience libraries (like libgsinterfaces-*.la should be first followed by system libs like gst/gtk. if you disagree with this behavior, you can ask on the libtool lists: http://lists.gnu.org/mailman/listinfo/libtool
What I'm trying to do is not rocket science, it's in fact a very common usage imho. What i put down was my investigation of what *MIGHT* be the problem, alas trying to debug a multi-thousand lines shell script dating from the dark ages (aka libtool) seems to require a nuclear physicist. Those were just my findings, they could be wrong. The variables that are different in libtool just blow my mind, I can understand the fact they're not meant to be changed, but The fundamental problem remains the same. The exact reason I need this to work is for GStreamer development. Those wrappers *should* use the uninstalled libraries when you run them before make install. On all other systems I know of (fedora, ubuntu, debian) which use the exact same version of libtool, this works perfectly fine, and it will use the specified uninstalled library and NOT the system-wide one because the library search path will be properly set in the wrapper (i.e. (1) search in specified paths, (2) search in env variable LD_LIBRARY_PATH, (3) search in system paths). This is definitely a problem with gentoo and has appeared within the past 12months (I can't give a better estimate). When running the generated wrapper on karmik with LD_DEBUG=help, I get the following: 16594: find library=libgstinterfaces-0.10.so.0 [0]; searching 16594: search path=/home/bilboed/work/devel/gst-plugins-base/gst-libs/gst/interfaces/.libs (RPATH from file /home/bilboed/work/devel/gst-plugins-base/tests/examples/seek/.libs/lt-seek) 16594: trying file=/home/bilboed/work/devel/gst-plugins-base/gst-libs/gst/interfaces/.libs/libgstinterfaces-0.10.so.0 When running it on gentoo I get the following: 6270: find library=libgstinterfaces-0.10.so.0 [0]; searching 6270: search path=/usr/lib64 (system search path) 6270: trying file=/usr/lib64/libgstinterfaces-0.10.so.0 6270:
libtool isnt that hard to read. at any rate, you didnt try anything of what i suggested. the LD_LIBRARY_PATH order comes directly from the library order you specified in LDADD (which a trivial test would have already shown you). your convenience/local libraries should be first in the list, not last.
also, your cursory survey of other distros lacks any sort of real details. how debian/ubuntu operate is wholly irrelevant considering they go around deleting pretty much all of the libtool linker (.la) scripts. a quick check of FC9 shows similar behavior.
Why is libtool adding system library paths to LD_LIBRARY_PATH in its generated .la files (used uninstalled)?
libtool is doing exactly what it's told. you gave it a libtool linker script with a path set to /usr/lib64/.
