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

Re: .la file status and hint to clear the dependency_libs field

On Mon, 30 May 2011 12:23:35 +0200
Vincent Lefevre <vincent@vinc17.net> wrote:

> On 2011-05-27 00:17:45 +0200, Michael Biebl wrote:
> > Am 26.05.2011 23:26, schrieb Luk Claes:
> > 
> > > There are some good reasons to keep some specific *.la files around,
> > 
> > Just curious: what are these reasons / use case for keeping la files?
> They are at least read by libtool.

That is why dependency_libs can be cleared unconditionally but removal
of the .la file itself needs to be done in a sequence where the leaf
libraries have their .la files removed first, then the packages which
those .la files would have referenced. This is the depended_on listing
in the original analysis data:


Packages which are listed with a "depended_on" listing must not remove
the .la file until those dependencies remove their .la files or clear
their dependency_libs setting in the .la file. At that point, the file
above will list that package as "dependency_libs" only.

libtool will fail if a required .la file is not present - it will not
fail if the required .la file is present but has an empty
dependency_libs field. Equally, libtool is happy to not need any .la
files when dependency_libs fields are all empty. Arguably this utilises
a weakness in libtool in that it trusts the contents of the .la file
too much, thinking that it is the same content as libtool itself wrote
out originally. Once all the dependency_libs are clear, any package not
using .la files for plugin loading can then remove their .la files
without breaking any other package in the archive. The .la files then
(finally) become package-specific and have no impact on other packages.

The problem with .la files in Debian is that the data in the .la file
is inherently outdated as it is only completely regenerated when every
single package in the archive is rebuilt in a specific sequence. There
are simpler ways of updating dependency information. libtool's method
just doesn't suit what Debian requires.

> Either the information provided by /usr/lib/libgmp.la is important
> and this file should be kept, or libtool should not attempt to read
> the file... unless this doesn't matter for the specific case of
> /usr/lib under Debian.

libtool will not attempt to read the .la file of the next level of
dependencies if the dependency_libs field of the immediate dependencies
are empty.

$ grep 'dependency_libs=' /usr/lib/*.la

Where the output lists explicit file paths
(like /usr/lib/libpangoft2-1.0.la) then those listings need to be
removed by clearing the entire dependency_libs field.

The package build process in Debian deals with providing the
information in ways which are controllable within the single package
build instead of using, what is essentially, archived data from
previous builds as is preserved in the .la files of dependencies.


Neil Williams

Attachment: pgpdHQTPBdLk5.pgp
Description: PGP signature

Reply to: