Hi Feri,
wf...@niif.hu wrote:
[SNIP]
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
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.
Regards,
Roumen Petrov
