autoconf
[Top][All Lists]
Advanced

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

Re: AC_PROG_CC wrongly setting $GCC=yes while clang is used


From: Bastien Chevreux
Subject: Re: AC_PROG_CC wrongly setting $GCC=yes while clang is used
Date: Mon, 8 Sep 2014 20:36:03 +0200

On 08 Sep 2014, at 18:37 , Marko Lindqvist <address@hidden> wrote:
>> Maybe it's as simple as patching autoconf to change the message to
>> "checking whether the compiler understands GNU C extensions", to match
>> the reality of how it works these days.
> 
> The $GCC example brings up another problem, though. Even though
> autoconf itself works perfectly by treating clang as gcc (and clang++
> as g++), user scripts may not. Is there need to update documentation
> abour $GCC to say that it should not be taken literally, but just to
> mean some kind of gcc compatibility.

So I’ve learned quite a deal in this thread: once I knew the specifics of the 
autoconf test I had lots of fun reading up a number of pages all across the net 
as I’ve not been the first to fall into this trap (see e.g. 
http://rem.eifzilla.de/archives/2012/08/10/identify-theft-by-clang ).

I think part of the problem is the wording in the GCC manual regarding __GNUC__ 
(https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html):
  If all you need to know is whether or not your program is being compiled by 
GCC,
  ***or a non-GCC compiler that claims to accept the GNU C dialects,***
  you can simply test __GNUC__.

The problem is this “or compiler that claims” sentence: I think they shot 
themselves in the foot by allowing that. No wonder clang, icc (and maybe 
others) start to define __GNUC__ themselves … without ever reaching 100% 
compatibility this is bound to fail at some point.

Would it be worthwhile to forward this to the GNU compiler maintainers so that 
they could maybe correct their course by maybe introducing a define which is 
‘reserved’ for telling that, yes, this is indeed a GNU compiler?

A developer (maybe a non-autoconf-expert like me) who needs to write a 
configure.ac only every once in a while and who does not know all these nitty 
gritty little details will very probably fall into the trap of assuming that 
the autoconf $GCC is yes when autoconf assures me within reasonable bounds that 
the compiler is indeed from the GNU CC. Especially when looking at tons of 
already existing autoconf scripts as examples which all go like this:

  if test $GCC = yes ; then
    # ok, we have gcc, set special flags for it
    …
  else
    # need to test /set flags for other compilers
    ...
  fi

I very much would expect, as programmer, to have autoconf AC_PROG_CC set 
- for gcc/g++ et al:  GCC=yes ;  GNUC=yes
- clang, icc (and maybe other that define __GNUC__):  GCC=no;  GNUC=yes

Which brings me to what sparked my initial mail to the list: is there somewhere 
in the autoconf system a macro which gives back the compiler family of the used 
compiler so that one can take some action? Something which would set a variable 
(e.g. COMPILER_FAMILY) so that one can write something like this:

case $COMPILER_FAMILY in
gnu)
  …
;;
clang)
  …
;;
icc)
  …
;;
sunc)
  …
;;
hpc)
  …
;;
# (and others)
esac

Best,
  Bastien

reply via email to

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