[Top][All Lists]

[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     
>>  NEEDED     
>>  NEEDED     
>> is unneeded here (but is present in the installed program as
>> well).  Coincidentally, the most prominent search result
>> 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
(This thread is too broad already, let's discuss that in a new one if
you've got the bandwidth.)

reply via email to

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