libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Trouble controlling linking if many library versions are installed


From: Johnny Lam
Subject: Trouble controlling linking if many library versions are installed
Date: Sat, 9 Mar 2002 08:29:12 -0800

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 <address@hidden>

Attachment: ltmain.diff
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]