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

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

> 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

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: