(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 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] > 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 <[EMAIL PROTECTED]> http://people.redhat.com/djr/ http://naim.n.ml.org/ Never be afraid to try something new. Remember: Amateurs built the ark. Professionals built the Titanic. _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool