[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Libtool 1.5.8 released.

From: Daniel Reed
Subject: Re: GNU Libtool 1.5.8 released.
Date: Tue, 10 Aug 2004 12:37:03 -0400 (EDT)

(Hiya. I have recently become Red Hat's libtool package maintainer.)

On 2004-08-11T00:32+0900, Peter O'Gorman wrote:
) Joe Orton wrote:
) > It always disappoints me to do so too, that's why I'm making this plea
) > :) The fact that libtool 1.5-based configure scripts fail on systems
) > without a C++ compiler is a severe regression which outweighs all the
) > great features and fixes since 1.4, unfortunately.
) I guess I must have seen this report at some point, but I don't remember
) having done so :(

I have reported it at least twice, with several months in between. It had
been reported numerous times by others and has been reported numerous times
since :/

For my own projects, I patch the affected routines via acinclude.m4 to noop
the C++ checks. The patch I use was originally posted here, probably over a
year ago (it guts an M4 macro).

However, I am hesitant to make such a change to Red Hat's shipped version of
libtool. For one, the patch I am using disables C++ support entirely (my
affected projects are just C). Most importantly, though, this is an actual
[and serious] flaw in the autotools, and should be addressed in the
upstream, canonical versions.

On a related note, the libtool I inherited already has 5 patches applied to
it. I would like to eventually ship a "clean" libtool, and would love to
hear back on what the status of these patches are. From the previous
  >   libtool-1.4-nonneg.patch

  Afaik this patch is not strictly necessary, but doesn't do any harm either.
[it changes some shell script in libtool to detect non-negative numbers better]

  >   libtool-1.5-libtool.m4-x86_64.patch

  I guess this should go upstream if it is not in cvs stable branch
  already.  It trivial but obviously needed to support hammer/ia32e.

  >   libtool-1.4.2-multilib.patch

  This patch is needed for multilib support.  It has been sent upstream
  but basically rejected in its current form as being too Red Hat specific.
[Is this still the case? Is there an alternate solution for this problem, or
 is .multilib still the only one?]

  >   libtool-1.4.2-demo.patch (on x86_64 s390 s390x)

  Yes, this is just to disable several nopic tests: afaicr nopic is
  meaningless on those archs bicbw... ie a patch should really go upstream
  to skip those tests on those archs I guess.

  >   libtool-1.5-testfailure.patch

  This was contributed by Owen: would probably be worth trying to
  push it upstream - though I'm not entirely clear why/if it is needed.

I can post these to libtool-patches if the names are unfamiliar to anyone :)

Daniel Reed <address@hidden>
Never be afraid to try something new. Remember: Amateurs built the
ark. Professionals built the Titanic.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]