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]
I create two shared libraries, libfoo and libbar, and libbar has an
interlibrary dependency on libfoo and on libssl and libcrypto (lines
wrapped for readability):
# libtool cc -o libfoo.la -rpath /tmp/lib
mkdir .libs
cc -shared -nodefaultlibs -Wl,-soname -Wl,libfoo.so.0 -o .libs/libfoo.so.0.0
(cd .libs && rm -f libfoo.so.0 && ln -s libfoo.so.0.0 libfoo.so.0)
(cd .libs && rm -f libfoo.so && ln -s libfoo.so.0.0 libfoo.so)
(cd .libs && rm -f libfoo.so && ln -s libfoo.so.0.0 libfoo.so)
ar cru .libs/libfoo.a
ranlib .libs/libfoo.a
creating libfoo.la
(cd .libs && rm -f libfoo.la && ln -s ../libfoo.la libfoo.la)
# libtool cc -o libbar.la -rpath /tmp/lib -lssl -lcrypto libfoo.la
cc -shared -nodefaultlibs -Wl,--rpath -Wl,/home/jlam/tmp/.libs \
-Wl,--rpath -Wl,/tmp/lib -lssl -lcrypto ./.libs/libfoo.so \
-Wl,-soname -Wl,libbar.so.0 -o .libs/libbar.so.0.0
(cd .libs && rm -f libbar.so.0 && ln -s libbar.so.0.0 libbar.so.0)
(cd .libs && rm -f libbar.so && ln -s libbar.so.0.0 libbar.so)
(cd .libs && rm -f libbar.so && ln -s libbar.so.0.0 libbar.so)
ar cru .libs/libbar.a
ranlib .libs/libbar.a
creating libbar.la
(cd .libs && rm -f libbar.la && ln -s ../libbar.la libbar.la)
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 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?
Thanks,
-- Johnny Lam <[EMAIL PROTECTED]>
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