Re: Development packages.
On Mon, Mar 22, 2004 at 04:26:49PM +0100, Frank Küster wrote:
> Stephen Frost <sfrost@snowman.net> schrieb:
> > * Adrian 'Dagurashibanipal' von Bidder (avbidder@fortytwo.ch) wrote:
> >> On Sunday 21 March 2004 20.49, Stephen Frost wrote:
> >>
> >> > .la files shouldn't be included in anything, they're just plain broken.
> >>
> >> 940 .la files on my system. Report bugs?
> > [...]
> >> So either you don't mean that absolutely, or three's a few buggy
> >> packages out there.
> > It's the glorious brokenness that is libtool. Basically, libtool needs
> > to be fixed to not use the stupid things on systems that don't need them
> > (like, oh, all of Debian). I don't know that filing bug reports would
> > be useful until libtool is fixed because I imagine most maintainers who
> > havn't actually run into the problems caused by .la files will just
> > whine "libtool did it".
> Yes, it did :-|. Could you point me to a documentation where I could
> read about these problems, and under what weird circumstances it will be
> a bug nevertheless if I don't install the *la files?
[...]
Hello,
Basically the essence of the mess is #191425. If libfoo links against
libbar and application blah makes use of libfoo (but does not use
libbar) libtool will link the application against both libraries.
This is not necessary for dynamic linking on reasonably unbroken
platforms like GNU/Linux and complicates matters a lot:
Dependencies are immensly bloated. For example check the
dependencies of ghex (a simple Hex-Editor). It links directly
against libtasn1-0 although it sure as hell does not parse ASN
certificates. This can make make migration to testing a lot more
painful.
Now, if libfoo is replaced by libfoo2 and libbar is rebuilt against it
the application blah sudenly links against both libfoo2 and libfoo. If
these libraries do not use versioned symbols you'll get symbol clashes
and segmentation faults.
Now libtool gets this information (libfoo links against libbar) from
the .la file, if you do not ship it, libtool cannot be that stupid and
link against all these dependcies. - The price you pay for that is
that _static_ linking does require following these dependency chains.
Personally I think the payoff is ok, due to dlopen in glibc (NSS,
iconv) static linking is unreliable anyway.
If you want to see a nice example for the results of this bug, check
e.g. apt-cache showpkg libtasn1-0 and ask yourself how many of these
packages really should link against it.
cu andreas
PS: Be aware that I do not maintain a library myself, I have just
done one or two NMUs and have followed discussions on the issue.
PPS: I gather that pkgconfig is also broken.
Reply to: