bug-libtool
[Top][All Lists]
Advanced

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

Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 6


From: Peter O'Gorman
Subject: Re: [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, 06 Mar 2008 13:57:56 -0600
User-agent: Thunderbird 2.0.0.9 (X11/20071115)

Ralf Wildenhues wrote:
> * Bob Friesenhahn wrote on Thu, Mar 06, 2008 at 08:43:15PM CET:
>> On Thu, 6 Mar 2008, Peter O'Gorman wrote:
>>> I think the test for a working GCJ should be in libtool, and unset GCJ,
>>> avoid adding the tag etc.if it is found to be nonfunctional. We would
>>> have to issue a warning during configure or something. Does not look to
>>> be quite as easy as this patch though, if you want to apply this one as
>>> a stop-gap measure, that is fine.
> 
> I'm considering doing that (the stop-gap measure).

Your call.

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

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




reply via email to

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