autoconf
[Top][All Lists]
Advanced

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

Re: libtool--release--2.0 test results


From: Ralf Corsepius
Subject: Re: libtool--release--2.0 test results
Date: Wed, 06 Oct 2004 06:57:14 +0200

On Tue, 2004-10-05 at 16:33, Peter O'Gorman wrote:
> Gary V. Vaughan wrote:
> 
> > I bootstrapped libtool with the autoconf-2.59 release, so maybe this bug is
> > fixed in CVS autoconf?
> > 
> > Gary V. Vaughan wrote:
> > 
> >>hppa2.0-hp-hpux10.20:  3 of 85 tests failed [[All tagdemo-make]]
> > 
> > 
> > Anyway these fail because of this:
> > 
> 
> Yeah, I should have forward ported my patch to the libtool branch-1-5 
> configure.ac, sorry. Won't take but a minute.
> 
> But yes, it is very annoying that g++ is returned when no valid c++ compiler 
> is found.
ACK, it's a classic autoconf usability limitation :(

>  Is there any valid reason for this?
AFAICT, this has to causes:

1. AC_CHECK_TOOL[S] resort to TOOL if they can't find a tool.
This had been discussed many times for many years, but IIRC all
proposals to change this behavior had been rejected, so far.
IIRC, the original reason for this behavior was GCC which applied
(applies?) this hack at some places. Another reason was (is !)
unclarity/lack of tool-naming conventions wrt. cross compilation in
autoconf. (Some people expect cross-tools to be named "$host-<tool>"
others expect "<tool>")

2. Another reason is a behavioral bug having been introduced in early
autoconf-2.5x: autoconf does not support conditionally checking for
compilers.

Things like 
AC_PROG_CC
if test "$enabled_cxx" = yes; then
AC_PROG_CXX
fi

don't work, due to deficiencies in autoconf's "REQUIRE"-processing.

This also had been discussed many times before, but ... nothing has
happened so far.

Ralf






reply via email to

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