bug-autoconf
[Top][All Lists]
Advanced

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

AC_PROG_CC mistaken clang for GCC (was: Re: bug#10859: 1.11a head on OSX


From: Stefano Lattarini
Subject: AC_PROG_CC mistaken clang for GCC (was: Re: bug#10859: 1.11a head on OSX Lion with Clang - 173 fails 87 skips of 2854 tests)
Date: Tue, 21 Feb 2012 22:52:13 +0100

[CC:ing bug-autoconf]

Reference:
  <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10859>

On 02/21/2012 09:44 PM, Panther Martin wrote:
> 
>> On Feb 20, 2012, Stefano Lattarini <address@hidden> wrote: 
>>
>> Hmm... this doesn't ring a bell right away, even after I've looked into the
>> attached logs.  Could you please send the content of the 'config.log' file
>> that should have been left in the 'tests/silent2.dir' directory?
>
> I can see from that log that the test did not collect CC from my environment,
>
Ah, but that's intended: this test case requires GCC, so it overrides your
choice of the compiler.  That is OK.  The problem is that the test is not
managing to properly clobber your CFLAGS as well, as it would be supposed
to do:

  > configure:2674: checking whether the C compiler works
  > configure:2696: gcc -Os -w -pipe -march=native -Xclang -target-feature ...

which unsurprisingly leads to a spurious error:

  > cc1: error: unrecognized command line option "-aes"
  > conftest.c:1: error: bad value (native) for -march= switch
  > conftest.c:1: error: bad value (native) for -mtune= switch
  > configure:2700: $? = 1
  > configure:2738: result: no

And I think I understand the reason of this failure: the get-sysconf.log
reveals that the automake's own configure script has mistakenly identified
clang as a GCC variant (and I'm CC:ing bug-autoconf for this):

  > configure:3611: checking whether we are using the GNU C compiler
  > configure:3630: /usr/bin/clang -c -Os -w -pipe -march=native -Xclang ...
  > configure:3639: result: yes

So the automake testsuite thinks that your configure-time CFLAGS, being
tailored to a GCC compiler, are OK also for this gcc-requiring test, and
fails to reset them.  Hilarity ensues.

Now that we have identified the problem, fixing it shouldn't be too difficult;
I will follow-up in the next days with a patch.

Thanks for all your help so far,
  Stefano



reply via email to

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