Invoquant la GCC en tant que "cc" et "gcc"

Question

Je suis conscient que, sur la plupart des systèmes GNU/Linux, GCC peut être invoquée par le nom de "cc" à partir de la ligne de commande (par opposition à "gcc"). Quelle est la différence dans le comportement de GCC lorsqu'il est appelé d'une manière par rapport à l'autre?

Par exemple, je sais que l'invocation de GCC par le nom de "g++" au lieu de "gcc" causes GCC à se comporter différemment (il traite .c les fichiers C++ source et liens-dans le C++ standard library). Est-il similaire différence de comportement entre les "gcc" et "cc"?

EDIT: Aucune des réponses reçues jusqu'à présent a donné un définitif "oui" ou "non" si GCC se comportent différemment lorsqu'elle est invoquée rapport à l'autre. Cependant, l'idée compte tenu de plonger dans la source pour vérifier son comportement me conduire dans cette voie. Basé sur ce que j'ai trouvé là, maintenant, je crois que la réponse est:

Pas de. GCC se comporte de la même, peu importe si elle est appelée par l'intermédiaire de "gcc" ou "cc".

Answer 1

Pour sourire, je viens de retracer comment argv[0] est utilisé dans gcc (principale.c -> top_lev.c -> opts.c -> langhooks.c) et il semble que argv[0] est actuellement utilisé pour rien de plus que de donner des malloc quelque chose à rapporter lorsqu'il échoue. Il ne semble pas être tout changement de comportement si argv[0] est rien d'autre que gcc.

Answer 2

Il me semble que l' cc (lien vers quelques vieux SUS spécification) est destiné à être le fournisseur neutre de l'interface pour le système du compilateur. Elle est marquée comme héritage:

Le c89 utilitaire offre une interface à la norme ISO C standard, mais le cc utilitaire accepte un quelconque dialecte du langage C: il peut être de série C, de l'union de l'utilisation de la C ou une autre variante. C Portable programmes doivent être écrits pour être conformes à la norme ISO standard C et compilé avec c89.

POSIX est un utilitaire appelé c99 qui, je crois, est le successeur de l' c89. Il dit

Le c99 utilitaire est basé sur le c89 utilitaire été introduit à l'origine dans la norme ISO POSIX-2:1993 standard. Certains des changements de c89 inclure la modification du contenu de la Norme section des Bibliothèques pour tenir compte des nouveaux en-têtes et les options; par exemple, ajouté à l'-l rt opérande, et l'option-l de trace opérande ajoutée pour le Traçage des fonctions.

Je ne suis pas vraiment familier à toutes les personnes qui sont différentes des normes, mais il semble que la plus récente SUSv3 (POSIX:2004) et le plus récent POSIX:2008 (ne semble pas avoir un SUS du nombre encore) ne spécifiez pas un utilitaire appelé cc plus, mais seulement l'utilitaire c99. D'ailleurs, mon système Linux (Arch_Linux) contient une page de manuel de c99 mais pas c89, mais ne contient qu'un utilitaire appelé cc, mais ni c89 ni c99. Beaucoup de confusion là-bas :)

Answer 3

Sur mon mac à partir d' man gcc:

D'Apple dans la version de GCC, les deux cc et gcc sont en fait des liens symboliques vers un compilateur nommé comme gcc-version. De même, c++ et g++ sont des liens vers une compilateur nommé comme g++-version.

Basé sur que je suppose que le cc et gcc se comportent de la même manière.

Answer 4

J'ai eu le même doute aujourd'hui et j'ai essayé de le trouver sur mon propre:

$ which cc
 /usr/bin/ccc

$file /usr/bin/cc
 /usr/bin/cc: symbolic link to '/etc/alternatives/cc'

$file /etc/alternatives/cc
 /etc/alternatives/cc: symbolic link to '/usr/bin/gcc'

$which gcc
 /usr/bin/gcc

Donc, en gros, cc points de gcc.

Vous pouvez aussi vérifier à l'aide de cc -v et gcc -v. Si ils imprimer la même chose, ce qui signifie qu'ils sont exactement la même.

Answer 5

Même si gcc exploite le même, indépendamment de argv[0] valeur, pas tous les logiciels fonctionneront de la même, peu importe qui vous préciser que le compilateur.

Lors de la construction de zlib 1.2.5 sur RHEL 5.5 (gcc 4.1.2):

$ md5sum $(which cc)
69a67d3029b8ad50d41abab8d778e799  /usr/bin/cc
$ md5sum $(which gcc)
69a67d3029b8ad50d41abab8d778e799  /usr/bin/gcc

Mais:

$ CC=$(which cc) ./configure
Checking for shared library support...
Tested /usr/bin/cc -w -c -O ztest20557.c
Tested cc -shared -O -o ztest20557.so ztest20557.o
/usr/bin/ld: ztest20557.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
ztest20557.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
No shared library support; try without defining CC and CFLAGS
Building static library libz.a version 1.2.5 with /usr/bin/cc.
Checking for off64_t... Yes.
Checking for fseeko... Yes.
Checking for unistd.h... Yes.
Checking whether to use vs[n]printf() or s[n]printf()... using vs[n]printf().
Checking for vsnprintf() in stdio.h... Yes.
Checking for return value of vsnprintf()... Yes.

Et:

$ CC=$(which gcc) ./configure
Checking for shared library support...
Building shared library libz.so.1.2.5 with /usr/bin/gcc.
Checking for off64_t... Yes.
Checking for fseeko... Yes.
Checking for unistd.h... Yes.
Checking whether to use vs[n]printf() or s[n]printf()... using vs[n]printf().
Checking for vsnprintf() in stdio.h... Yes.
Checking for return value of vsnprintf()... Yes.
Checking for attribute(visibility) support... Yes.

Le script configure ne pas envisager la possibilité que la cc sur un système Linux peut être gcc. Alors, soyez prudent dans quelle mesure vous prenez vos hypothèses.