[Top][All Lists]

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

compiler found but not functional (was: [libtool 2.2] testsuite: 19 35 3

From: Ralf Wildenhues
Subject: 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]
Date: Thu, 6 Mar 2008 21:03:35 +0100
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

* 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

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.


reply via email to

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