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

[Axel Thimm]

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 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...
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20061004/321799b5/attachment.sig>