[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: transitive shared library dependencies and installation

From: Roumen Petrov
Subject: Re: transitive shared library dependencies and installation
Date: Sun, 12 Jan 2020 12:25:01 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.5

Hi Feri,

address@hidden wrote:
On the other hand, this overlinks the final binary:
$ objdump -p .libs/translib | fgrep NEEDED
   NEEDED      is unneeded here (but is present in the installed program as
well).  Coincidentally, the most prominent search result
Urgh, article with very limited niche. First is only for shared libraries, next unresolved externals in shared library, and finally requires "advanced" loader.

For instance on Microsoft Windows shared library (DLL) does not allow "unresolved symbols". Remark: Initial example requires -no-undefined flags as library LDFLAGS (libtool requirement) for mingw* builds. Even that fact that for executable build command includes all libraries linker may exclude some of them. I guess that this is because usually build uses "import libraries". Dunno what is behavior if build is directly with DLLs.

Another system is Android. System allows unresolved externals but loader is quite simple. To load dynamically shared library is must not contain unresolved externals.

Static build: partial or complete. There is no rule in general. Linker picks required symbols from archives and may require some dependent libraries. So in some cases environment variable PKG_CONFIG set to pkg-config --static is solutions.

  mentions that
"this is fixed using a patch from Debian" for libtool.

I wonder why is patched libtool.
Libtool is not only Debian. Is is supposed to work on all supported OS-se, distributions and etc. Because of those "fixes" it is mandatory to bootstrap source tarbal generated on Debian with M4 macros from FSF sources.
Now I do this unconditionally on all source tarballs - it save my time.

What's your position on this?  Is overlinking a problem or not?  (It
causes problems for distributions.)
No Idea. I guess that this is more related to the rules describing package dependencies. A package could be split into multiple sub-package. A project may produce one "big" library or several "small" libraries. In both cases upgrade of related package is maintenance hassle.

Topic is not for libtool . It is more general.

Should everybody use --as-needed
globally to combat it?  Something else entirely?

On some OS-es --as-needed is enabled by default. I'm not aware why this model was chosen instead "s/tatus quo"./

As needed is fine with limited shared library format like those used on Microsoft windows  (COFF?) - no unresolved, no weak symbols. In the past loader does not guarantee that load of library follow dependency rules.

Also as needed may break use of weak aliases (ELF format).

I'm not sure that libtool respect order of linker options like --no-as-needed or --as-needed.

As alternative could be used patchelf.

It seems to me question is how to remove some extra dependencies : automatically (--as-needed) or manually (using tools like patchelf).

May be topic is not for libtool list.

Roumen Petrov

reply via email to

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