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

[Axel Thimm]

On Mon, Oct 02, 2006 at 03:34:09PM +0200, Enrico Scholz wrote:
> Axel.Thimm at ATrpms.net (Axel Thimm) writes:
> 
> >> 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?
> 
> I do not know whether it would solve all issues, but the bad library-deps
> should be solved. But how shall such a fix be applied in practice?
> 
> 1. somebody has to write a patch against ltmain.sh and probably
>    libtool.m4. Quick look into ltmain.sh indicates that this is not
>    a trivial job (some archs do not support indirect linking and
>    need a graph like above).

We currently care about Linux, so we'd need that patch for Linux at
the beginning. More platforms could add themselves to the whitelist as
they see fit.

> 2. somebody has to convince libtool people to apply this patch. Does not
>    seem to be trivial either (look at the more or less trivial multilib
>    patch in the Red Hat libtool-package which is still not applied).

I wouldn't derive from one patch to another. What you perhaps consider
trivial and acceptable may be different for the upstream authors and
vice versa. I also didn't notice any discussion about the multilib
patch on the libtool list, so perhaps this wasn't even submitted?

>    Because this change is more an improvement than a bugfix and changes
>    behavior significantly, it will be a candidate for upcoming libtool-2
>    but not for current libtool-1.5.
> 
> 3. Most upstream authors will not use a beta versions of libtool. Hence,
>    a huge amount of packages will need a 'libtoolize' (or 'autoreconf')
>    against the patched libtool. This is heavily discouraged.

This is just our policy. If we decide it serves us better, then it
will be changed.

> It seems to be much easier to omit *.la files completely because they do
> not offer anything (which might be relevant for dynamic linking).
> 
> 
> > 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.
> 
> I do not see which workflows are affected. *.la files are an holdover of
> the last millennium. No recent system requires them.

You missed the beginning of this discussion: There *are* packages of
this millenium that break when *.la files are blindly
removed. Therefore Rex is trying to setup a workflow of when to omit
or not *.la files.

Better fix something than deal with broken stuff after the fact is my
opinion. Even if *.la files would had turned out to be completely
unneccessary - which they are not, but let's suppose - then it would
be better to had libtool patched up.
-- 
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/c0641054/attachment.sig>