[Fedora-packaging] Re: libtool(.la) archive policy proposal

[Michael Schwendt]

On Mon, 2 Oct 2006 12:32:12 +0200, Axel Thimm wrote:

> | Here's a crazy-but-not-too-far-from-reality example: Build shared-lib
> | pkg 'b' which links against 'a'. b's .la files now include references
> | to 'liba.la' (so now depends on it). Build shared-lib pkg 'c' which
> | links against 'b', whose own libc.la file includes
> | references(+dependancy) on libb.la. Rinse, lather, repeat. You'll end
> | up with a pkg z, and a libz.la, which, when all is said and done,
> | 
> |     * will have a direct dependancy upon y's liby.la
> |     * and because of liby.la file references/dependances, will have
> |     (indirect) dependancies upon liba.la, libb.la, ..., libx.la
> | 
> | When, generally, *none* of these are really required nor desired.
> 
> I'm not sure about that, but maybe I understand something wrongly:
> 
> - If -la was needed for building libb, then there exists a real
>   dependency between liba and libb and libb.la is correct about that.

So far so good. But here, mixing of build-time and run-time dependencies
starts. Run-time deps enter the build-time dep-chain. Add Rex's "c" to the
set. "c", which needs just "b" at build-time, sees the indirect dep on "a"
(=> liba.la) through libb.la. libb-devel needs to "Requires: liba-devel"
just because of a .la dependency.

At build-time, shared-lib "c", which only requires libb, links via
libb.la, which in turn needs liba.la (because libb.la lists it as a
dependency). And it creates in libfoo.la the more complex libb.la ->
liba.la dep-chain. Application "foo", which needs only libfoo, now also
needs libb.la + liba.la when the linking is done via libfoo.la instead of
just -lfoo. 

The BuildRequires pile up -- unless the packagers fix them bottom-up
because they examine the new .la file(s). If they don't, wrong BR move up
in the dep-chain. Guess what happens if libfoo is upgraded and now
build-requires libd.la.  This requires additional BR in "foo", although
"foo" doesn't depend on libd directly.

Worse, libtool inter-library dependencies often are hardcoded as
absolute paths, e.g. /usr/lib/liba.la.

Removal of any .la from the entire dep-chain bears a very big risk of
requiring a rebuild of the entire dep-chain bottom-up plus pruning the
spec BR/Reqs, also bottom-up.

> From a different view: *.la files aren't much different than *.pc
> files, in fact they contain a subset of their information. One
> wouldn't argue to remove all *.pc files because some may contain too
> many references to libs.

These are broken and partially have their origin in "extreme static
linking". (For static linking you need the full chain of -lfoo arguments,
as everything else would result in missing symbols).

pkgconfig "Requires" in libfoo.pc should list the options that are needed
to build with libfoo, NOT the options that were used to build libfoo. With
sane linking, the shared libfoo has a run-time dep already on any other
libs it needs and is linked against, e.g. liba and libb, so adding -la -lb
and so on is not needed when linking shared against -lfoo.