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

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

 



On 08 Sep 2014, at 18:37 , Marko Lindqvist <cazfi74@xxxxxxxxx> 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
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf





[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux