On Mon, Oct 02, 2006 at 02:11:58PM +0200, Enrico Scholz wrote: > Axel.Thimm@xxxxxxxxxx (Axel Thimm) writes: > > > | 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. > > No, this dependency does not need to be handled explicitly with dynamic > libraries. > > E.g. a dep-tree of > > liba.so -> libb.so -> libc.so -> app > > would suffice. Having the '-la' in libb.la and '-lb' in libc.la would > cause a tree like > > --------------------------- > / ,---------------- \ > / / `v v > liba.so -> libb.so -> libc.so -> app > \ ^ > `----------------' > > > Unfortunately, widely used tools like 'libtool' or 'cmake' are creating > such trees (at least when the libs and apps are in the same project). For > 'cmake' there is a workaround to put '-Wl,--as-needed' into the linker > flags but for 'libtool' you have to patch ltmain. E.g. you argue that this is a bug in libtool. So, if libtool were to simply ignore dependency_libs when building against shared libs wouldn't that solve all issues? If so the patch looks almost trivial and is far better than to setup workflows on whether removing some *.la files and still have some false positives/negatives. -- Axel.Thimm at ATrpms.net
Attachment:
pgpJuUpMLBwEc.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
