On Mon, Oct 02, 2006 at 09:43:26PM +0200, Axel Thimm wrote: > On Mon, Oct 02, 2006 at 09:01:34PM +0200, Enrico Scholz wrote: > > 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... > > Wow, looks like there already exists such a patch and that this patch > only changes about a dozen lines. So much for a non-trivial job. ... > > http://people.debian.org/~keybuk/keybuk-linux-deplibs.patch > > I raised this up on the libtool list, which is probably better than > guessing around. Looks like Debian is using this patch for some time > now. I was told that this is still not the best way to slice bread, > and am waiting for further details. OK, after browsing through the Debian bugs related to this patch it looks like there are two issues, both of which are fixable and not really a blocker for Fedora packaging: o When libtool is told not to remember the dependent libs/rpaths of shared builds, a library being built as a subproject of a build may later be overrideen by an older version of itself under %{_libdir}. This will never happen in a clean chroot build, but can happen with conventional non-package builds. But this happens outside of libtool anyway, an example is rpm itself that cannot be properly built in presence of rpm-devel. A fix could be a switch to turn this only on for packaging, or a proper permanent fix in libtool. o Cross-compilation of libs may also lose their rpath and try the system's rpath. A similar issue like above in a different domain. Concerning upstream libtool, there is no input from vendors, be it Red Hat, Debian, Fedora etc. to push in patches or enhancements. This is true for multilib and the mentioned patch the same. The reasons look like vendor lazyness. For example both Debian and Red Hat have their 10-line patches for years in their packages but never properly sumbitted this upstream or even tried to raise the issue to a level where libtool maintainers would address it. In the past there have been some small momentum from the outside, libtoolers then had some _positive_ discussion on the matter, but the feedback was missing. I think if someone here outlines the issues/desires to upstream then libtool may have both patches plus further needed fixes in upstream really soon. I have started doing so, but I'm not going to fight in fedora-packaging for a lost cause again, I'll let someone else bleed his heart here this time. ;) Of course that would only affect new upstream tarballs of libtoolized projects, so any packaging using such an improved system libtool on older tarballs would need to libtoolize. -- Axel.Thimm at ATrpms.net
Attachment:
pgp14UItSHYVA.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
