On Mon, Oct 02, 2006 at 03:34:09PM +0200, Enrico Scholz wrote: > Axel.Thimm@xxxxxxxxxx (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
Attachment:
pgp1Vj0xbWlVV.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
