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 -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging