Re: transitive shared library dependencies and installation

[wferi]

Bob Friesenhahn <address@hidden> writes:

> On Wed, 1 Jan 2020, address@hidden wrote:
>
>> make[1]: Leaving directory '/home/wferi/ha/pacemaker/translib'
>> make: *** [Makefile:798: install-am] Error 2
>>
>> No cyclic dependencies here, so this can be worked around by
>>
>> -lib_LTLIBRARIES = a/liba.la b/libb.la
>> +lib_LTLIBRARIES = b/libb.la a/liba.la
>>
>> in this case; is this expected (and documented) behavior?
>
> 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.

>> 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.)

> 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.

> 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.
-- 
Thanks,
Feri