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

Re: .la file status and hint to clear the dependency_libs field

On Mon, May 30, 2011 at 12:16:13PM +0100, Simon McVittie wrote:
> On Mon, 30 May 2011 at 12:23:35 +0200, Vincent Lefevre wrote:
> > They are at least read by libtool. For instance, when building MPFR
> > (as a normal user):
> [...]
> > Either the information provided by /usr/lib/libgmp.la is important
> > and this file should be kept, or libtool should not attempt to read
> > the file... unless this doesn't matter for the specific case of
> > /usr/lib under Debian.

> It doesn't matter for the specific case of /usr/lib under Debian. Debian's
> libtool has appropriate behaviour (read .la files if found, but fall back
> to just using the real library if not).


This is upstream libtool behavior.  Debian doesn't attempt to diverge from
upstream here, because that would basically require rerunning libtoolize on
all affected source packages.  I know some developers favor this approach,
but it's not universally agreed and it indisputably requires more effort
from the maintainer to keep the source package buildable with current
autotools than to ship the pre-built ones from upstream.  So until and
unless there's a consensus that packages should be built this way, with
build-depends on libtool and the whole nine yards, there's little point in
improving libtool in Debian to have more sensible Debian-ish behavior; and
conversely it would make Debian less fit as a platform for people doing
upstream development and expecting upstream-compatible libtool behavior.

If someone wants libtool to behave more sanely in the absence of referenced
.la files when doing dynamic linking, please find a way to get that
incorporated upstream. :)

> libtool .la files are useful if:

> * you're linking against a library installed in a directory that isn't
>   searched by the dynamic linker by default (e.g. installing a local
>   library in --prefix=$HOME, and a program that links that library -
>   but this isn't relevant for packaged libraries in /lib or /usr/lib,
>   which are searched by default anyway)

I can't think of a reason this should actually be true on GNU/Linux.  A
/path/to/lib.so option should give libtool all the information it needs to
synthesize the correct rpath options.

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: