On Sat, Oct 11, 2003 at 03:54:08PM -0500, Branden Robinson wrote: > On Sat, Oct 11, 2003 at 10:57:38AM -0500, Steve Langasek wrote: > > On Sat, Oct 11, 2003 at 03:21:50AM -0400, Joey Hess wrote: > > > I'm coming into this thread very late, with what may be a stupid > > > question, but can anyone tell me if the breakage could be avoided by > > > just deleting the .la files in question?
> > Yes, it can. I've advocated this on a number of occasions where .la > > files were doing more harm than good. They are really only of use when > > working with static libs (which is almot never the case in Debian > > itself), or when making poor use of ltdl plugin loaders. > Please propose a policy amendment that is worded clearly enough that > slope-heads like me can undersand it. If I was comfortable that .la files were completely dispensable on GNU/Linux systems, I wouldn't hesitate to do that, but I'm not. They *do* provide additional information that's useful to people linking applications statically; and while we never (rarely) use the static libs ourselves, policy does require us to ship them in packages, so it makes sense to also provide the additional glue information in the .la's whenever possible. When it causes problems for shared libs, though, I think it's clear which should take precedence. > E.g., libxft-dev (currently stuck in queue/new), ships a libXft.a static > object, but I suspect that's not what you meant by "working with static > libs". The .la file that accompanies any given .a file tells libtool what other objects that static lib depends on. If anyone is ever going to *use* these static libs we're shipping, it's useful information to have available. On the shared library side, we already have the NEEDED field in ELF libs which is more elegant; so the .la's are redundant (and, indeed, can get in the way). I understand Scott is working on fixing libtool so that it doesn't try to redundantly link applications when running on systems that have the required support. -- Steve Langasek postmodern programmer
signature.asc
Description: Digital signature
