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

Re: MBF: Getting rid of unneeded *.la / emptying dependency_libs



On Tue, Apr 05, 2011 at 08:41:37AM +0100, Neil Williams wrote:
> > > > This apparently just isn't true.  I could have sworn that we had a check,
> > > > but we apparently do not.  We definitely should.  That's probably why
> > > > there are so many problems; I suspect a lot of them would go away if there
> > > > were a Lintian check.

> > > As outlined previously, this does need to be done in a fairly strict
> > > sequence which is external to the package. It might be hard for lintian
> > > to make this into an error for all packages. 

> > > Many packages (all those in the list with depended-on) must not touch
> > > their .la files at this stage - including the dependency_libs listing.

> > That's not correct.  It is safe for any package to clear out the
> > dependency_libs field of any .la file, as far as the OS is concerned.  It is
> > a (rather intractable) upstream bug in libtool that it recurses these .la
> > files at all at build time when doing dynamic linking on Linux, and the only
> > difference between a populated and an empty dependency_libs field for a
> > package build is whether or not you get a build failure because a referenced
> > .la file is missing.

> I'm trying to avoid those build failures, hence not asking for
> changes in packages which still have dependencies which will look for
> the dependency_libs data at build-time. Those packages only get bugs
> filed when those dependencies have been fixed to either clear
> dependency_libs or remove the .la file.

You're not avoiding the build failures.  The build failures are *caused by
the non-empty dependency_libs field*.

This is why the first step should be to try to empty out all the
dependency_libs fields, because this can be done archive-wide without
breaking anything.

> > Now, removing this information will impact *static* linking using libtool;
> > but that's already largely broken due to the preceding dependency_libs
> > removals in the archive, and the number of packages doing static linking in
> > Debian can be counted on one hand - none of them using libtool AFAIK.
> 
> Exactly. I'm still not sure if it's worth retaining the .a if the .la
> is removed. I think for "high-end" libraries like GUIs or any library
> which depends on a long list of other libraries, the likelihood of
> anyone needing a static linkage of the entire stack is infinitesimal. I
> am thinking that libts-dev should retain the .a but I'm open to
> comments to the contrary. Currently, I'm thinking of simply removing
> the .la file from libts-dev.

Static linking didn't begin with libtool and doesn't end with it.
pkg-config is sufficient to handle the static linking use case for packages,
if those libraries support pkg-config.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature


Reply to: