On Mon, 4 Apr 2011 16:12:42 -0700 Steve Langasek <vorlon@debian.org> wrote: > On Mon, Apr 04, 2011 at 07:33:24PM +0100, Neil Williams wrote: > > > >> Lintian already checks that *.la files don't contain the problematic > > > >> dependency_libs setting. > > > > 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. e.g. once I fix gpe-expenses to not contain the .la in libqofexpensesobjects-dev, then qof can be fixed to not include the .la file in libqof-dev because libpilotobjects-dev has already been fixed and so it goes on. The nice thing about this MBF is that it can all be done within the Debian revisions of the packages concerned. There are no upstream requirements here, no changes in debian/patches, so every bug is potentially fixable with a trivial NMU - as long as the sequence is followed, we shouldn't see any increase in FTBFS bugs due to this MBF. > 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. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpAZmx8y3Y06.pgp
Description: PGP signature