Re: How to convince maintainer to use --as-needed?
* Dmitry Smirnov <onlyjob@member.fsf.org> [120211 02:50]:
> But sometimes an innocent call to library causing package to inherit the whole
> hierarchy of needless dependencies.
> And this affect not just obvious things like slower start-up and installation
Once one library is actually needed, the whole hierachy is still pulled
in at run-time recursively. (And as those are dependencies of the
dependencies, they are installed anyway, so no benefits at installation
time).
> Package maintainers can surely track problems to --as-needed if that's the
> case and here we have hope because many packages using it already for years
> successfully.
How many package maintainers know all the functions of their
applications and regularily test all of them?
> > Unless you are entangled in libraries ignoring usual best practises and
> > ignoring library borders in their headers (libglib, libboost), there
> > might be better solutions than --as-needed.
>
> I'd like to learn more about --as-needed alternatives.
> Could you suggest any resources/guidelines, please?
--as-needed is used mostly a solution used against uneeded libararies
linked against. It can make more sense to fix the build system or work
around it to cause the reason instead of the symptoms.
There are mostly 6 cases:
1) No symbols of the library are needed, but it's initialisation code
does things (like enabling extra functionality and the like).
In this case --as-needed break things.
2) a program is linked against a library without any reason
here just removing the -l is all that is needed to do.
3) a program is linked against a library as another program created
from the same build system needs it. This might need bigger
modernisations in the upstream build system (like not using
the outdated generic LIBS with autoconf but instead export that
as special variable). As this has direct benefits for the generated
binary that is usually easy to get upstream.
4) libraries linked against because they are dependencies of libraries
needed. This is usually done so that it is also possible to link
programs statically. Getting this fixed upstream is usually not that
easy.
5) libraries sometimes needed and sometimes not needed, depending
whether something is inlined or not. This can be harder to fix
upstream. It might be fixable locally if that is the same on all
debian architectures. Here --as-needed has the biggest advantages,
though it can make sense to limit it to one library.
(-Wl,--as-needed -lm -Wl,--no-as-needed).
6) libraries whose headers make the program call functions from other
libraries. Those may look like 4) but one can never know which
libraries are actually used, so it is not easily fixed. So here
there might be no other solution that --as-needed, but it's effects
are also limited, as those libraries will not likely change incompatibly
independently (at least not the dependet on without the depending
library and if they do a recompile might still be needed as the used
headers might no longer be compatible).
Note that many build systems can be modified without needing patching
by giving them make variables. This can be easy with case 4 (just
overriding the variable containing the libs with less libs), but in
most cases impossible for case 3 (as everything is in one variable).
> Surely there must be software incompatible with --as-needed. But what are the
> chances to experience it? How to identify situation when --as-needed is likely
> to cause troubles?
The likely causes of trouble I can think of are:
- libraries needed only for their initializers
- libraries where order matters because of their initializers (like libXaw)
- a program inlining stuff incompatible with a different library loaded
Bernhard R. Link
Reply to: