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

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

On Mon, Oct 13, 2003 at 09:02:06PM +0200, Josselin Mouette wrote:
> Le dim 12/10/2003 à 03:31, Steve Langasek a écrit :
> > 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.
> All this additional information can be provided as well by pkg-config,
> which is much more flexible and doesn't cause random breakages.

$ pkg-config libgnomecanvas-2.0 --libs
-Wl,--export-dynamic -lgnomecanvas-2 -lart_lgpl_2 -lpangoft2-1.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0  

Hmm, nope, pkg-config can at least cause one of the most popular forms
of libtool breakage, which is that applications will be linked
unnecessarily against indirect library dependencies, making ABI
transitions much more difficult than they should be.

It also doesn't even provide a complete list of all the indirect library
dependencies, so this pkg-config line will even fail on platforms where
libtool will succeed.  (E.g., try to statically link a binary using the
above list without having to append '-lX11'.)  And if you use the
pkg-config output as input for a libtool-using application, you'll get
double the pleasure.

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: