Appeller GCC comme « cc » par rapport à « gcc »
https://stackoverflow.com/questions/939989
-
06-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Je suis conscient du fait que la plupart des systèmes GNU / Linux, GCC peut être invoqué à partir de la ligne de commande par le nom « cc » (par opposition à « gcc »). Est-ce qu'il ya une différence dans le comportement de GCC lorsqu'il est invoqué d'une façon par rapport à l'autre?
Par exemple, je sais que l'invocation du CCG par le nom « g ++ » au lieu de « gcc » provoque GCC se comporter différemment (il traite les fichiers .c en tant que source C ++, et les liens dans la bibliothèque standard C ++). Est-ce qu'il ya une différence similaire entre le comportement « gcc » et « cc »?
EDIT: Aucune des réponses reçues à ce jour a donné un définitive « oui » ou « non » pour savoir si GCC se comportera différemment si elle est invoquée dans un sens par rapport à l'autre . Cependant, l'idée donnée de plonger dans la source pour vérifier son comportement me conduire dans cette voie. Sur la base de ce que je trouvai, je crois maintenant que la réponse est:
Non. GCC se comporte de la même indépendamment du fait qu'il est appelé par "gcc" ou "cc" .
La solution
Pour des grimaces, je viens de tracer vers le bas comment argv[0] est utilisé à l'intérieur gcc ( main.c -> top_lev.c -> opts.c -> langhooks.c) et il semble que argv[0] est actuellement utilisé pour rien de plus que de donner quelque chose malloc signaler quand il échoue. Il ne semble pas y avoir de changement de comportement si argv[0] est autre chose que gcc.
Autres conseils
Il me semble que cc (lien vers une ancienne spécification SUS ) est destiné à être l'interface fournisseur neutre au compilateur du système. Il est marqué comme héritage:
L'utilitaire C89 fournit une interface à la norme ISO C, mais l'utilitaire cc accepte un dialecte non précisé de la langue C: il peut être standard C, C-usage courant ou d'une autre variante. Les programmes portables C doivent être écrits pour se conformer à la norme ISO C et compilé avec C89.
a Posix un utilitaire appelé c99 que je crois est le successeur de c89. Il dit
L'utilitaire C99 est basé sur l'utilitaire C89 initialement introduit dans la norme ISO-2 Posix: norme 1993. Certains des changements de C89 comprennent la modification du contenu de la section des bibliothèques standard pour tenir compte des nouveaux en-têtes et des options; par exemple, ajouté à l'opérande -l rt, et l'opérande de trace -l ajoutée pour les fonctions de traçage.
Je ne suis pas vraiment au courant de toutes ces différentes normes, mais il ressemble plus SUSv3 récente ( Posix: 2004 ) et les : 2008 (ne semble pas avoir un numéro de SUS encore) ne spécifie pas un utilitaire appelé cc plus, mais seulement l'utilitaire appelé c99. Soit dit en passant, mon système Linux ( Arch_Linux ) contient une page de manuel c99 mais pas c89, mais ne contient que un utilitaire appelé cc, mais ni c89 ni c99. Beaucoup de confusion là-bas:)
Sur mon mac de man gcc:
Dans la version d'Apple de GCC, à la fois 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 un compilateur nommé comme g ++ - version.
Sur cette base, je suppose que cc et gcc se comportent de la même manière.
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
Alors, essentiellement des points cc à gcc.
Vous pouvez également vérifier à l'aide cc -v et gcc -v. S'ils impriment la même chose, cela signifie qu'ils sont exactement les mêmes.
Même si gcc fonctionne de la même indépendante de argv [0] valeur de, tous les logiciels fonctionnera même, quel que soit spécifié comme le compilateur.
Lors de la construction 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
$ 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.
$ 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 de configuration ne considère pas la possibilité que cc sur un système Linux pourrait être gcc. Alors, soyez prudent dans quelle mesure vous prenez vos hypothèses.
cc est juste la façon UNIX d'appeler le compilateur, il fonctionne sur tous les systèmes Unix.
ce fil est peut-être vieux mais je veux ajouter quelque chose (Peut-être quelqu'un trouvera dans l'avenir).
Si vous compilez ce programme
#include <stdio.h>
#include <stdlib.h>
void
myFunction(char *args)
{
char buff1[12];
char buff2[4] = "ABC";
strcpy(buff1,args);
printf("Inhalt Buffer2: %s",buff2);
}
int main(int argc, char *argv[])
{
if(argc > 1)
{
myFunction(argv[1]);
}
else
printf("no arguments sir daimler benz");
getchar();
return 0;
}
avec « gcc », et vous passez « AAAAAAAAAAAAAAAAAAAAAAAAA » comme argument, il ne sera pas déborder dans buffer2, alors qu'il ne si vous avez compilé avec « cc », qui pour moi est une allusion au fait que si vous avez utilisé « gcc », la gestion de la mémoire fonctionne différente, peut-être en mettant l'espace entre les segments de mémoire des champs Buff1 et buff2?
Peut-être quelqu'un avec plus experiance peut mettre la lumière dans l'obscurité ici.
Rien dans la documentation de GCC indique que GCC se comporterait différemment si son nom de l'exécutable est pas gcc et cc . Le compilateur GNU Fortran même mentionne que :
Une version de la commande gcc (qui peut également être installé en tant que la commande du système cc)
"Non. GCC se comporte de la même indépendamment du fait que il est appelé par gcc ' ou 'cc'. »
[Cité du message original.]
Sur la base de mon expérience dans Ubuntu 14.04, cela n'a pas été le cas.
Quand je compile mon programme en utilisant:
gcc -finstrument-functions test.c
Je ne reçois aucun changement dans le comportement de mon code. Mais quand je compile en utilisant
cc -finstrument-functions test.c
Il ne se comporte différemment. (Dans les deux cas, j'intégré les changements appropriés dans mon code décrit ici pour rendre le travail -finstrument-fonctions).
Compte tenu de cela vient UNIX, je dirais que « cc » est le nom générique et « gcc » est le compilateur réel. dire « gcc » fournit « cc » pour un programme de recherche « cc » trouverait et utiliser « cc », parfaitement ignorants du compilateur réel utilisé.
En outre, les programmes UNIX doivent ignorer le nom réel utilisé pour les appeler (pensez raccourcis bureau Windows - il n'a pas de sens pour vérifier ce que le raccourci a été appelé), donc, non, « gcc » et « cc «faire la même chose si « cc » est un lien vers « gcc ».
À moins, bien sûr, "cc" est pas un lien symbolique mais shellscript appelant gcc.
Pour mon OS (Ubuntu 14.04) cc ne permet pas la complétion, alors que gcc fait.
