Axel.Thimm@xxxxxxxxxx (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
Attachment:
pgpyKKQEcYwuA.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
