[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: |
Mon, 06 Jan 2020 11:24:09 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Bob Friesenhahn <address@hidden> writes:
> On Sun, 5 Jan 2020, address@hidden wrote:
>
>> On the other hand, this overlinks the final binary:
>>
>> $ objdump -p .libs/translib | fgrep NEEDED
>> NEEDED liba.so
>> NEEDED libb.so
>> NEEDED libc.so.6
>>
>> libb.so is unneeded here (but is present in the installed program as
>> well). Coincidentally, the most prominent search result
>> https://wiki.mageia.org/en/Overlinking_issues_in_packaging mentions that
>> "this is fixed using a patch from Debian" for libtool.
>>
>> What's your position on this? Is overlinking a problem or not? (It
>> causes problems for distributions.) Should everybody use --as-needed
>> globally to combat it? Something else entirely?
>
> This has been the most common complaint (in the GNU Linux world) I
> have heard about libtool. There is a choice of working reliably and
> portably (with possible over-linking) or relying on implicit library
> dependencies (which are definitely not portable), or failing as you
> have encountered.
Is the presence of over-linking a portability aspect? I mean, couldn't
libtool overlink only where it's unavoidable, and link precisely on
systems which allow this (via -rpath-link or other means)?
> A similar complaint is that libtool uses information in installed
> ".la" files in order to link with all libraries that the
> program/library is dependent on.
This is the exact same issue as above, isn't it?
> Due to this, GNU Linux distributions often patch out this capability,
> and they don't distribute ".la" files.
Yes, I think they are (meant to be) replaced by pkg-config, and distros
have little interest in static linking or ltdl anyway (with a few
exceptions, like ImageMagick). And ELF shared objects carry their
dependency information internally.
> Unfortunately, --as-needed may not be 100% reliable since it only
> reliably detects direct dependence on library symbols, and not
> "transitive" dependence.
Maybe I misunderstand you, but that's its very point in my opinion.
Anyway, the most trouble with it seems to originate from libtool
reordering the linker flags when creating shared libraries, making
--as-needed ineffective by moving it to the end of the command line.
At least this used to be the case, see
https://stackoverflow.com/questions/6852414/how-do-i-link-a-shared-library-with-as-needed-with-automake
(This thread is too broad already, let's discuss that in a new one if
you've got the bandwidth.)
--
Thanks,
Feri
- Re: transitive shared library dependencies and installation, (continued)
Re: transitive shared library dependencies and installation, Roumen Petrov, 2020/01/04
- Re: transitive shared library dependencies and installation, wferi, 2020/01/04
- Re: transitive shared library dependencies and installation, Roumen Petrov, 2020/01/04
- Re: transitive shared library dependencies and installation, wferi, 2020/01/04
- Re: transitive shared library dependencies and installation, Roumen Petrov, 2020/01/05
- Re: transitive shared library dependencies and installation, wferi, 2020/01/05
- Re: transitive shared library dependencies and installation, Bob Friesenhahn, 2020/01/05
- Re: transitive shared library dependencies and installation,
wferi <=
- Re: transitive shared library dependencies and installation, Roumen Petrov, 2020/01/12
- Re: transitive shared library dependencies and installation, Russ Allbery, 2020/01/12
- Re: transitive shared library dependencies and installation, Roumen Petrov, 2020/01/19
Re: transitive shared library dependencies and installation, Bob Friesenhahn, 2020/01/04
Re: transitive shared library dependencies and installation, wferi, 2020/01/04
Re: transitive shared library dependencies and installation, Russ Allbery, 2020/01/04
Re: transitive shared library dependencies and installation, Bob Friesenhahn, 2020/01/04