Re: transitive shared library dependencies and installation

Bob Friesenhahn <[email protected]> writes:

> On Thu, 2 Jan 2020, [email protected] 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.

I think libtool could support arbitrary shared library dependencies by
using the -rpath-link option as necessary.

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

I suspect it's just outdated documentation.  What --enable-new-dtags
does is adding DT_RUNPATH instead of DT_RPATH to ELF objects.  See which
one you find after building my example.

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

Neither do I, but I think it would be a possible way out of this
situation.  I wonder what the reason could be for libtool not using it.

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

Yes, and liba indeed has the build directory libb.la in its
dependency_libs, so the information is there and could be used with
-rpath-link, unless I'm missing something important.

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

But that causes overlinking, which is unpopular.  And I'm not sure
--as-needed could help here.

> If the .la file passed to libtool mentions the dependencies, then
> libtool is supposed to do the right thing.

I think it does, see above.  Libtool still fails to link the executable
if an incompatible library is already installed (and you use a custom
--prefix).

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

It's rather hard to get support for libtool, but I sorely need some,
because this issue hurts a real software project.  Since this is the
first time I seriously deal with libtool, I certainly miss most of the
picture, so I sincerely appreciate your "piping up".  Let's hope others
will join with time with their insights.
-- 
Thanks,
Feri