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
> | to 'liba.la' (so now depends on it). Build shared-lib pkg 'c'
> | 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
(=> 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
Removal of any .la from the entire dep-chain bears a very big risk
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
> 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
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
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).