Re: GNU Libtool 1.5.8 released.

[Peter O'Gorman]

Daniel Reed wrote:

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

Hi Daniel,

> 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 :/

I've already apologized and posted a patch asking for confirmation that it 
works to this list (sorry, should have posted it to -patches, but it was 
after 2am).

> 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
> maintainer:
>   >   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]

For some reason currently we check for non-negative 1-3 digit numbers, 4 
digits are reported as negative. Whee. Post this to patches and I'll apply it.

>   >   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.

This too.

>   >   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?]

Do you have a url for the thread?

>   >   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.

Well, if you can be bothered to make a real patch, we might look at it. A 
patch that simply removes tests from the Makefile.am is not a good thing[tm] :).

>   >   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 not understand the point of this one. Perhaps Owen can explain why it 
is needed.

Peter
--
Peter O'Gorman - http://www.pogma.com