Re: Trouble controlling linking if many library versions are installed

[Steve Tell]

Johnny Lam address@hidden writes:

> I'm having a problem with linking against the proper shared libraries
> on my system.  On my NetBSD-1.5.2/i386 machine, I have the following files:
> 
>         /usr/lib/libssl.so      [System-supplied    ]
>         /usr/lib/libcrypto.so   [  OpenSSL (0.9.5.a)]
> 
>         /tmp/lib/libssl.so      [Newer OpenSSL          ]
>         /tmp/lib/libcrypto.so   [  installed from source]

[snip] 

> Now, if I try to install libbar.la now, the following relink_command is
> executed (culled from libbar.la:relink_command):
> 
> libtool --mode=relink cc -o libbar.la -rpath /tmp/lib -lssl -lcrypto \
>     libfoo.la
> 
> which invokes:
> 
> cc -shared -nodefaultlibs -Wl,--rpath -Wl,/tmp/lib -lssl -lcrypto \
>     -L/tmp/lib -lfoo -Wl,-soname -Wl,libbar.so.0 -o .libs/libbar.so.0.0
> 
> The problem I'm experiencing comes about because "-L/tmp/lib" is injected
> into the link command.  This causes libbar.so to use the libssl and
> libcrypto from /tmp/lib instead of the ones in /usr/lib.  But, in this
> particular case, I really want to link against the ones in /usr/lib.


I've just slammed straight into exactly the same problem while
building guile-1.5.6 on a RedHat 7.1 linux system.  The dlopen-able
helper library libguilereadline depends on libguile.  But when libtool
pollutes the gcc command line with -L/usr/lib during relinkin, the old
/usr/lib/libguile.so.9 gets found, instead of the new libguile.so.9
version which is being installed into the alternate prefix /usr/guile-1.5.6/lib

the relink command
        ./libtool --debug --mode=relink gcc -g -O2 -o libguilereadline.la 
        -rpath /usr/guile-1.5.6/lib -version-info 15:0:1 -export-dynamic 
        -no-undefined readline.lo ../libguile/libguile.la -lreadline -lncurses

is becomming
        gcc -shared readline.lo -Wl,--rpath -Wl,/usr/guile-1.5.6/lib 
        -L/usr/lib -L/usr/guile-1.5.6/lib -lguile -lreadline -lncurses 
        -Wl,-soname -Wl,libguilereadline.so.14 
        -o .libs/libguilereadline.so.14.1.0

In additional experimention, I found that simply removing -L/usr/lib
altogether works in this case, perhaps because of the --rpath.
"Correct" for me here is building a libguilereadline.so that depends
explicitly on the versioned name libguile.so.14 (which I guess will be
searched for at runtime)

> I've found that the following patch to ltmain.in will cause "libfoo.la"
> to be replaced by "/tmp/lib/libfoo.so" in relink_command, instead of
> "-L/tmp/lib -lfoo", which is the current behaviour.  What are the problems
> associated with this change on other platforms?  Does this fail for
> non-GCC compilers?


The same patch also fixes my problem.  From the comments in the
script, it appears that libtool can't explicitly hardcode the full
library pathname, so it gives up and falls back to the generic
"-L$libdir -l$name"

In my case, the (GNU ld specific?) behaviour of encoding a versioned
.so name into the library is what saves the day.  Even though this
versioning isn't quite in line with the libtool goal of hardcoding
pathnames, I'd say it is better than nothing.  Any chance libtool
could take better advantage of it?  The the patch below seems to do so.

This is my first venture into the libtool code, so I'd greatly
appreciate further enlightenment if there's a reason this change fails
elsewhere and can't be configured appropriately.



>         -- Johnny Lam <address@hidden>

> Index: ltmain.in
> ===================================================================
> RCS file: /cvsroot/libtool/libtool/ltmain.in,v
> retrieving revision 1.288
> diff -c -r1.288 ltmain.in
> *** ltmain.in   3 Mar 2002 03:19:54 -0000       1.288
> --- ltmain.in   9 Mar 2002 16:04:00 -0000
> ***************
> *** 2278,2285 ****
>               add="-l$name"
>             else
>               # We cannot seem to hardcode it, guess we'll fake it.
> !             add_dir="-L$libdir"
> !             add="-l$name"
>             fi
> 
>             if test "$linkmode" = prog; then
> --- 2278,2284 ----
>               add="-l$name"
>             else
>               # We cannot seem to hardcode it, guess we'll fake it.
> !             add="$libdir/$linklib"
>             fi
> 
>             if test "$linkmode" = prog; then





In the full if/else statement being modified above, I note with
interest that if hardcode_direct=yes, it does the right thing.

            # Finalize command for both is simple: just hardcode it.
            if test "$hardcode_direct" = yes; then
              add="$libdir/$linklib"
            elif test "$hardcode_minus_L" = yes; then
              add_dir="-L$libdir"
              add="-l$name"
            elif test "$hardcode_shlibpath_var" = yes; then
              case :$finalize_shlibpath: in
              *":$libdir:"*) ;;
              *) finalize_shlibpath="$finalize_shlibpath$libdir:" ;;
              esac
              add="-l$name"
            else
              # We cannot seem to hardcode it, guess we'll fake it.
              add="$libdir/$linklib"
            fi


thanks,
Steve


--
Steve Tell  address@hidden