[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Trouble controlling linking if many library versions are installed
From: |
Steve Tell |
Subject: |
Re: Trouble controlling linking if many library versions are installed |
Date: |
Mon, 11 Mar 2002 22:54:37 -0500 (EST) |
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