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

Enrico Scholz enrico.scholz at informatik.tu-chemnitz.de
Mon Oct 2 13:34:09 UTC 2006


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).

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).

   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.


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.



Enrico
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20061002/a41b68d4/attachment.sig>


More information about the Fedora-packaging mailing list