détecter gcc - Page 1

j'ai une compil conditionnelle qui dépend du compilateur (bah ué y'a des boulets de clients qui préfèrent le compilo arm officiel ici)

pour vérifier que j'utilise bien gcc, c'est quelle macro? la macro __GNUC__ est-elle ok pour ça?

Oui.

merci.

Non.
__GNUC__ est définit pour dire que le compilateur supporte le GNU LANGUAGE C (ou C++) et non pas que c'est le compilateur GNU C.
Voir mailing list de gcc.
Si le compilateur ARM support le GNU language, ca va pas marcher (mais c'est peu probable).

et donc?

je détecte comment?

(l'autre compilo c'est ADS je sais pas si c'est connu.)

PpHd (./4) :
__GNUC__ est définit pour dire que le compilateur supporte le GNU LANGUAGE C (ou C++) et non pas que c'est le compilateur GNU C.

__GNUC__ est défini pour dire que c'est GCC, après il y a des compilateurs concurrents (en général propriétaires, genre ICC d'Intel) qui abusent et définissent le même symbole pour faire compiler les sources écrites pour GCC sans modifications, mais cette pratique est très mal vue. Le problème est que le projet GCC ne peut pas empêcher cette pratique (pour les mêmes raisons pour lesquelles on ne peut pas empêcher MinGW de définir _WIN32, donc ce n'est pas forcément une mauvaise chose).

Enfin bon, ce n'est pas si grave que ça normalement, parce que si le compilateur définit __GNUC__, c'est pour dire qu'il est compatible GCC, et donc il a intérêt à gérer aussi le code qui est dans le #ifdef __GNUC__. La plupart des compilateurs ne gèrent pas toutes les extensions GNU et donc ne définissent pas __GNUC__ non plus (ça ne leur apporterait de toute façon rien s'ils ne visent pas à compiler les sources écrites uniquement pour GCC).

Kevin Kofler (./6) :
__GNUC__ est défini pour dire que c'est GCC, après il y a des compilateurs concurrents (en général propriétaires, genre ICC d'Intel) qui abusent et définissent le même symbole pour faire compiler les sources écrites pour GCC sans modifications, mais cette pratique est très mal vue. Le problème est que le projet GCC ne peut pas empêcher cette pratique (pour les mêmes raisons pour lesquelles on ne peut pas empêcher MinGW de définir _WIN32, donc ce n'est pas forcément une mauvaise chose).

This is our mistake. Originally __GNUC__ meant that this was the GNU C
compiler (aka GNU Compiler Collection). However, we have added so many
extensions to the compiler that it later came to mean that this is the GNU
C language. There is unfortunately no way to distinguish between a
program written in GNU C, and a program intended to be compiled by the GNU
C compiler. All compilers that implement the GNU C language must define
__GNUC__. There is no way around this. The use of __GNUC__ is so
pervasive in GNU/Linux that a compiler has to define it or else it simply
won't work. This is why the Intel compilers and other compilers define it.
They have no choice.

Source:http://www.nabble.com/Re:-Feature-request---a-macro-defined-for-GCC-p18227762.html

squalyl (./5) :
(l'autre compilo c'est ADS je sais pas si c'est connu.)

Comme j'ai dit, il est peu probable qu'il supporte le GNU C langaga, donc __GNUC__ est très bien. C'était juste une clarification d'une erreur courante.

C'est une opinion d'un développeur, d'autres développeurs ont dit à plusieurs reprises que c'est abusif. La seule chose sur laquelle ils sont d'accord est qu'il n'y a aucun moyen d'empêcher Intel de définir cette macro.

C'est un problème courant:
* Le logiciel X s'identifie avec CECI_EST_X.
* Le logiciel X implémente une extension utile à un langage et un protocole.
* De nombreux autres logiciels utilisent l'extension de X, avec "si CECI_EST_X, utiliser l'extension".
* Le logiciel Y implémente aussi l'extension de X.
Problème: tous les logiciels existants testent seulement X pour la fonctionnalité, pas Y. La solution propre serait de corriger tous les logiciels existants pour tester aussi pour Y. Mais l'éditeur de Y se dit: il y a plus simple, définissions CECI_EST_X et tous les logiciels fonctionneront sans modifications. Et c'est dommage, parce que ça dévalue la signification de CECI_EST_X et rend impossible de tester vraiment pour X si on en a besoin.

Ce n'est pas spécifique à __GNUC__, tout ça, ça se retrouve aussi avec les tables ACPI où le noyau Linux se fait passer pour un certain OS plus courant et à plein d'autres endroits.

À mon avis, redéfinir __GNUC__ en "ceci est le langage GNU C" et introduire une autre macro disant "ceci est GCC" ne servira à rien, les mêmes autres compilateurs qui définissent actuellement __GNUC__ vont se mettre à définir aussi cette autre macro.

Dans ce cas, il serait bien que tigcc ne définisse pas __GNUC__ car ce n'est pas le compilateur GCC

Kevin Kofler (./8) :
À mon avis, redéfinir __GNUC__ en "ceci est le langage GNU C" et introduire une autre macro disant "ceci est GCC" ne servira à rien, les mêmes autres compilateurs qui définissent actuellement __GNUC__ vont se mettre à définir aussi cette autre macro.

La solution est de définir une macro par extension supportée. Et pas regarder quelle version on a.

Pour l'histoire des tables ACPI: http://mjg59.livejournal.com/96129.html.

PpHd>

en fait j'ai trouvé que notre build system définit __GNU_GCC__ mais c'est un truc manuel donc si je builde pas avec le build system basique j'ai pas cette macro

donc je prends __GNUC__ en supposant que (pas gcc && __GNUC__ quand même) => le code #ifdeffé compilera.

en fait c'est pour protéger des

#define operation(param) ({ typeof(param) _truc=(param); machin(_truc)?bidule:_truc; })

Je me rappelle avoir eu un problème avec __GNUC__.
Je crois que c'était de l'ordre de "__GNUC__ non-défini si on compile en -ansi" ou un truc du genre...

Link (./13) :
Je crois que c'était de l'ordre de "__GNUC__ non-défini si on compile en -ansi" ou un truc du genre...

Tu dois confondre avec autre chose.