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

Axel Thimm Axel.Thimm at ATrpms.net
Mon Oct 2 12:37:03 UTC 2006


On Mon, Oct 02, 2006 at 02:11:58PM +0200, Enrico Scholz wrote:
> Axel.Thimm at ATrpms.net (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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20061002/90ee2332/attachment.sig>


More information about the Fedora-packaging mailing list