compiler found but not functional (was: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53) 60 61 62 64 failed [GNU/Linux PowerPC]

[Ralf Wildenhues]

* Peter O'Gorman wrote on Thu, Mar 06, 2008 at 08:57:56PM CET:
> Ralf Wildenhues wrote:
> > 
> > I'm considering doing that (the stop-gap measure).
> 
> Your call.

I've applied that now.

> > Yes, and I can conceive just as well a libtool-using package which may
> > optionally use a Java compiler, and thus its configure script should not
> > bail out at Libtool's whim either.
> 
> I agree, the way LT_LANG has worked so far is to test if a compiler for
> the language exists and is executable (or something similar), but not
> cause an error if it does not.
> 
> What would be ideal is to check that the compiler exists, is executable,
> works (an possibly, when not cross-compiling, test that trivial code
> that is compiled with the compiler runs) but not cause an error if the
> compiler is broken or does not exist, simply warn the user that a broken
> compiler was detected and set the same vars in the same way as would be
> set if no compiler was detected.

Actually I would have liked it if
  AC_PROG_{CC,CXX,F77,FC} and AM_PROG_GCJ

did the functionality testing, _and_ had an optional IF-FAILS argument,
defaulted to AC_MSG_ERROR.  That allows flexibility but has the right
default.  I think that would be enough, too: LT_LANG then would not have
to check for functional compiler.

Unfortunately, such an interface will break compatibility.

Cheers,
Ralf