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



reply via email to

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