Re: problems with LD_LIBRARY_PATH and libtool wrapper

[Ralf Wildenhues]

Hello Dan, all,

Thank you for this report.

* Dan McMahill wrote on Wed, Aug 20, 2008 at 03:55:19AM CEST:
> Ralf Wildenhues wrote:
>> * Dan McMahill wrote on Wed, Aug 13, 2008 at 11:06:41PM CEST:
>>> I have a problem with the LD_LIBRARY_PATH handling inside of the 
>>> libtool  wrapper.  I see a line like:
>>>
>>> # Add our own library path to LD_LIBRARY_PATH
>>> LD_LIBRARY_PATH="/usr/pkg/lib:/home/dan/src/myprog/libmine/.libs:$LD_LIBRARY_PATH"
>>>
>>> in /home/dan/src/myprog/src/myprog which is the libtool wrapper.
>>>
>>> The problem is I may have an out of date libmine installed in   
>>> /usr/pkg/lib and at runtime I pick that one up instead of the one in  
>>> /home/dan/src/myprog/libmine/.libs.  This has caused me great 
>>> confusion  a couple of times when I absolutely could not correlate 
>>> the behavior of  the program with the sources in ../libmine because 
>>> of course they didn't  match.
>>>
>>> It seems that we want to make sure any ".libs" directories appear 
>>> first  in LD_LIBRARY_PATH.
>>>
>>> Am I missing something obvious here?
>>
>> Could be.  Does myprog have an
>>   myprog_LDADD = ../libmine/libmine.la
>
> myprog_LDADD = @LIBMINE_LDADD@
>
> and at configure time @LIBMINE_LDADD@ either gets set to  
> ../libmine/libmine.la or something like -L/usr/pkg/lib -lmine.

OK.  First tangential issue: if you use @substitutions@ rather than
Makefile.am conditionals, then automake cannot see through them, and
you have to fix dependencies yourself.  IOW, you have to ensure that
myprog_DEPENDENCIES contains '../libmine/libmine.la' if myprog_LDADD
contains it.  In contrast, automake can figure it out itself with

if LOCAL_LIBMINE
myprog_LDADD = ../libmine/libmine.la
else
myprog_LDADD = ...
endif

This issue isn't your actual problem though.

> There is  
> a configure time option that says to either use a local build of the  
> library or use an already installed one.  This was done because there  
> are actually about 5 different programs that all use libmine that are  
> all included in the tarball.  This lets a third party packaging system  
> add the individual programs more easily.  The programs are all just  
> different front ends (gtk, cgi, commandline, scilab, octave, etc) to  
> libmine.

Sure, that's just fine.

> One thing I have realized is I do not have any version set for libmine  
> which is clearly not a good thing.

Agreed.

> Here is the link lines for the library (libwcalc)
>
> /bin/ksh ../libtool --tag=CC   --mode=link gcc  -g -O2 -Wall     -o  
> libwcalc.la -rpath /usr/local/lib air_coil.lo air_coil_loadsave.lo
[...]
>
> gcc -shared  .libs/air_coil.o .libs/air_coil_loadsave.o .libs/bars.o  
[...]
> .libs/wcalc_loadsave.o  -lm  -Wl,-soname -Wl,libwcalc.so.0 -o
>  .libs/libwcalc.so.0.0

> and here is the link for the program:
>
> /bin/ksh ../libtool --tag=CC   --mode=link gcc  -g -O2 -Wall  
> -Wl,-R/usr/pkg/lib
> -Wl,--rpath -Wl,/usr/pkg/lib -Wl,-R/usr/X11R6/lib -L/usr/pkg/lib  

Here's your problem: something adds
  -Wl,-R/usr/pkg/lib -Wl,--rpath -Wl,/usr/pkg/lib

to the link line of your program.  Find out what that is, probably
either some flag in your Makefile.am or a configure macro.
If you link the program without those flags, then it should work
as expected, namely, have the uninstalled program link against the
uninstalled library, and the installed program against the installed
library.  Problem with leaving them out is that they may just be
necessary for some other, independent library.


I'm still wondering whether this is a bug in libtool though.
Namely:

If the user passes run paths with -R to libtool, should these run paths
be reordered to always appear _after_ those run paths added by libtool
which point to uninstalled locations?

Note that we do similar for link paths passed with -L, see code in
ltmain commented with:
  # move library search paths that coincide with paths to not yet
  # installed libraries to the beginning of the library search list


Second issue: if the answer to the first question is yes, then in order
to do a good job of it, we'd have to not only detect '-R', but also
'-Wl,-rpath', '-Wl,--rpath' and whatever other system-dependent
notations there are.  That is almost certainly going to be very ugly.


[...]
> menus.o microstrip_gui.o print.o start.o stripline_gui.o version.o  
> wcalc.o AWG.o permeability.o permitivity.o resistivity.o units.o ../lib
> wcalc/libwcalc.la  -lm
[...]
> gcc -g -O2 -Wall -Wl,-R/usr/pkg/lib -Wl,--rpath -Wl,/usr/pkg/lib  
> -Wl,-R/usr/X11R6/lib -o .libs/wcalc about.o alert.o air_coil_gui.o  
[...]
> /usr/pkg/lib/libintl.so -lc ../libwcalc/.libs/libwcalc.so -lm -Wl,
> --rpath -Wl,/usr/pkg/lib -Wl,--rpath -Wl,/usr/local/lib

> Also I can just do
>
> ldd .libs/wcalc and see, among the other shared libs:
>
>         -lwcalc.0 => /usr/pkg/lib/libwcalc.so.0
>
> where that is an old version which is installed on the system.  The  
> reason I just don't delete the old version is the new one is still under  
> development and not ready for deployment.

That's ok, you shouldn't need to delete the old version.

Cheers,
Ralf