Re: transitive shared library dependencies and installation

[email protected]
Newsgroups gmane.comp.gnu.libtool.general
Message-ID <[email protected]>
Bob Friesenhahn <[email protected]> writes:

> On Sun, 5 Jan 2020, [email protected] 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.