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

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


Axel.Thimm at ATrpms.net (Axel Thimm) writes:

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

Defining and evaluating a 'whitelist' in ltmain.sh might be a problem...


>> 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?

Dunno; patch exists for 4 years already so I would wonder when it was never
submitted. I thought, RH packagers were active in libtool development but I
might be wrong here.


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

Ok; there are some projects from the last millenium which are still
requiring .la files. But it should be really trivial to fix them by
writing

| lt_dlopenext("libfoo");

instead of

| lt_dlopen("libfoo.la");


> Therefore Rex is trying to setup a workflow of when to omit or not
> *.la files.

.la files do not make sense nowadays and cause harm. E.g. look at
'/usr/lib/kde3/textthumbnail.la':

|dependency_libs='... /usr/lib/libidn.la'

What would happen when libidn switches to another buildsystem not
producing .la files anymore? RPM deps on libidn.so.11 would be still
correct but plugin would suddenly stop to work.

Then: .la files MUST NOT be shipped in the -devel package but in the main
one. Else, module loading will fail. I would not like such a rule...


Therefore: remove .la as far as possible and keep them only when they
are needed.

Rex's rules (no .la files in LD_LIBRARY_PATH) are ok, but I would see
them more as a guideline to decide whether a .la file is really required
than as a strict MUST rule.



> Better fix something

libtool is unfixable broken; adding features like correct RPATHs, linker
flags at proper place (e.g. '-Wl,--as-needed' before libs) or omitting
linking of indirect libs would require heavy changes in code which might
change the current behavior and break lot of other projects.

Adding a 200k sized bash wrapper around gcc does not seem to be a clever
idea either.



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/da2642f8/attachment.sig>


More information about the Fedora-packaging mailing list