[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: transitive shared library dependencies and installation
From: |
wferi |
Subject: |
Re: transitive shared library dependencies and installation |
Date: |
Thu, 02 Jan 2020 20:53:03 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Bob Friesenhahn <address@hidden> writes:
> 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.
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
- transitive shared library dependencies and installation, wferi, 2020/01/01
- Re: transitive shared library dependencies and installation, Bob Friesenhahn, 2020/01/01
- Re: transitive shared library dependencies and installation, wferi, 2020/01/01
- Re: transitive shared library dependencies and installation, Bob Friesenhahn, 2020/01/02
- Re: transitive shared library dependencies and installation,
wferi <=
- Re: transitive shared library dependencies and installation, Bob Friesenhahn, 2020/01/02
- Re: transitive shared library dependencies and installation, wferi, 2020/01/02
- Re: transitive shared library dependencies and installation, Bob Friesenhahn, 2020/01/02
- Re: transitive shared library dependencies and installation, Richard Purdie, 2020/01/03
- Re: transitive shared library dependencies and installation, Bob Friesenhahn, 2020/01/03
Re: transitive shared library dependencies and installation, Roumen Petrov, 2020/01/04