Axel.Thimm(a)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