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

[Ralf Corsepius]

On Mon, 2006-10-02 at 13:31 +0200, Michael Schwendt wrote:
> 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.
Yes, because libtool aims at portability. What you call "indirect deps"
is non-portable, therefore libtool keeps this info around.

> 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.
And what is the problem? Outside of the linux world, shared-libs are
non-relocatible.

> 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.
This is not a risk - this is a feature.

> > 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).
Wrong: They have their origin in portability. Only fully linking is
portable. Packages aiming at portability can not and must not avoid
these deps.

> 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.
>From a libtool focused perspective, *.la's and *.pc aim share some
aspects, that's all. *.la's provide features, *.pc provide others.

The main disadvantage of *.pc's is them not being automatically
generated which enables users to outsmart themselves by "presuming
portability on proprietary features" (Very common bug in linux sources).

Ralf