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

Re: Hardcoding of .la file paths in .la files

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

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

Attachment: signature.asc
Description: Digital signature

Reply to: