On Mon, Oct 02, 2006 at 03:34:09PM +0200, Enrico Scholz wrote:
Axel.Thimm(a)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