libtool
[Top][All Lists]
Advanced

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

Re: transitive shared library dependencies and installation


From: Bob Friesenhahn
Subject: Re: transitive shared library dependencies and installation
Date: Thu, 2 Jan 2020 08:40:08 -0600 (CST)
User-agent: Alpine 2.20 (GSO 67 2015-01-07)

On Thu, 2 Jan 2020, address@hidden wrote:

In this case libtool is a slave of Automake and Automake is
controlling the build and installation order.  This means that it
should be expected behavior.  Installation is serialized and thus
order matters.

But in case of a dependency cycle there's no correct order if libtool
insists on using the installation directory for the -L option for
relinking.  And the installation directory may contain an incompatible
version of the library anyway, just like it happens below.

Indeed, sometimes it is necessary to re-organize libraries and code in order to be successful given serialized linking.

and use it from liba, linking the final binary fails:

$ make
[...]
/bin/bash ./libtool  --tag=CC   --mode=link gcc  -g -O2 -avoid-version  -o 
translib translib.o a/liba.la
libtool: link: gcc -g -O2 -o .libs/translib translib.o  a/.libs/liba.so 
-Wl,-rpath -Wl,/tmp/translib/lib
/usr/bin/ld: a/.libs/liba.so: undefined reference to `b2'

As I understand it, the -rpath linker option on the above command makes
a/.libs/liba.so use the already installed (old) version of libb, which
lacks the b2 symbol.  What's the solution here?  Why isn't that -rpath
option "delayed" until the relinking phase?

The -rpath linker option did not cause the library to be used.

The above gcc linking command is successful if I omit the -rpath option.
(The built-in RUNPATH of liba.so contains the build directory first.
Just for the record: Debian's ld defaults to --enable-new-dtags.)

I am not sure exactly what --enable-new-dtags means, but Ubuntu 18.04 LTS's manual page says that this is not its default. This may indicate changing behavior.

The '-r' in -rpath stands for 'run' and thus it is a path stored in a
built shared library or executable which tells it where to search for
other libraries when th program is executed.

True, but man ld states in the -rpath-link option description that the
directories specified by -rpath options are used with a very high
priority for locating required shared libraries.

This is interesting but I am not seeing any use of -rpath-link in libtool.

Perhaps the controlling parameter is hardcode_into_libs.  If your
libtool comes from an OS distribution rather than from a FSF/GNU
tarball, then it is possible that its behavior may have been modified.

I don't know what to expect, here's what I can see:

$ ./libtool --config | fgrep hardcode_into_libs
hardcode_into_libs=yes

I am not seeing 'libb' mentioned on the link line and that may be the
cause of the problem you are seeing.

Sure enough, adding libb.la explicitly to the link command works around
the issue, but since the binary does not use libb directly, it doesn't
sound like a good solution to me, because it leads to overlinking.

Libtool can only know what has been passed to it via the command line and via the prior information it stored in the .la files (initially found due to the command line).

I have always found it to be good practice to include all dependency libraries in an Automake 'LIBADD' statement so that all dependency libraries are passed to libtool. If the .la file passed to libtool mentions the dependencies, then libtool is supposed to do the right thing.

At this point I am wondering why I am the only person on this list who has piped up with some sort of a response. :-(

Bob
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt



reply via email to

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