web-dev-qa-db-fra.com

Invoquer GCC en tant que "cc" contre "gcc"

Je sais que sur la plupart des systèmes GNU/Linux, GCC peut être appelé par le nom "cc" à partir de la ligne de commande (par opposition à "gcc"). Y a-t-il une différence dans le comportement de GCC lorsqu'il est invoqué dans un sens ou dans l'autre?

Par exemple, je sais que l'invocation de GCC via le nom "g ++" au lieu de "gcc" fait que GCC se comporte différemment (il traite les fichiers .c comme source C++ et les liens dans la bibliothèque standard C++). Existe-t-il une différence de comportement similaire entre "gcc" et "cc"?

EDIT: Aucune des réponses reçues jusqu'à présent n'a donné définitive "oui" ou "non" quant à savoir si GCC se comportera différemment s'il est invoqué dans un sens contre dans l'autre. Cependant, l'idée de plonger dans la source pour vérifier son comportement m'a conduit sur cette voie. Sur la base de ce que j'ai trouvé là-bas, je crois maintenant que la réponse est:

Non. GCC se comporte de la même manière, qu'il soit appelé via "gcc" ou "cc".

clinuxgcccompiler-constructiongnu
67
Dan Moulding

Pour les sourires, je viens de retracer comment argv[0] est utilisé depuis gcc ( main.c -> top_lev.c -> opts.c -> langhooks.c) et il semble que argv[0] n'est actuellement utilisé que pour donner à malloc quelque chose à signaler en cas d'échec. Il ne semble pas y avoir de changement de comportement si argv[0] est autre chose que gcc.

35
plinth

Il me semble que cc (lien vers une ancienne spécification SUS) est destiné à être l'interface indépendante du fournisseur du compilateur du système. Elle est marquée comme héritée:

L'utilitaire c89 fournit une interface avec la norme ISO C, mais l'utilitaire cc accepte un dialecte non spécifié du langage C: il peut s'agir du standard C, du C d'usage courant ou d'une autre variante. Les programmes C portables doivent être écrits pour se conformer à la norme ISO C et compilés avec c89.

POSIX possède un utilitaire appelé c99 qui je crois est le successeur de c89. Ça dit

L'utilitaire c99 est basé sur l'utilitaire c89 initialement introduit dans la norme ISO POSIX-2: 1993. Certaines des modifications par rapport à c89 incluent la modification du contenu de la section Bibliothèques standard pour tenir compte des nouveaux en-têtes et options; par exemple, ajouté à l'opérande -l rt et l'opérande -l trace ajouté pour les fonctions de suivi.

Je ne connais pas vraiment toutes ces normes différentes, mais il ressemble au SUSv3 plus récent ( POSIX: 2004 ) et au plus récent POSIX: 2008 (ne semble pas avoir de SUS pour le moment) ne spécifiez pas un utilitaire appelé cc plus, mais seulement l'utilitaire appelé c99. Par ailleurs, mon système Linux ( Arch_Linux ) contient une page de manuel de c99 mais non c89, mais ne contient qu'un utilitaire appelé cc, mais ni c89 ni c99. Beaucoup de confusion là-dedans :)

14
Johannes Schaub - litb

Sur mon mac depuis man gcc:

Dans la version Apple de GCC, 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.

12
stefanB

J'avais le même doute aujourd'hui et j'ai essayé de le trouver par moi-même:

$ 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 pointe vers gcc.

Vous pouvez également vérifier en utilisant cc -v et gcc -v. S'ils impriment la même chose, cela signifie qu'ils sont exactement les mêmes.

8
N 1.1

Même si gcc fonctionne de la même manière indépendamment de la valeur de argv [0], tous les logiciels ne fonctionneront pas de la même manière, quel que soit celui que vous spécifiez comme 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 de configuration ne considère pas la possibilité que cc sur un système Linux puisse être gcc. Alors, faites attention jusqu'où vous prenez vos hypothèses.

7
ednos

cc est juste la façon UNIX d'appeler le compilateur, il fonctionnera sur tous les Unices.

3
ismail

ce fil est peut-être ancien mais je veux y ajouter quelque chose (peut-être que quelqu'un le trouvera à l'avenir).

Si vous avez compilé 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 lui passez "AAAAAAAAAAAAAAAAAAAAAAAAA" comme argument, il ne débordera pas dans buffer2, alors qu'il FAIT si vous avez compilé avec "cc", ce qui pour moi est un indice que si vous avez utilisé "gcc", la gestion de la mémoire fonctionne différemment, peut-être en mettant de l'espace entre les segments de mémoire des champs buff1 & buff2?

Peut-être que quelqu'un avec plus d'expérience peut mettre de la lumière dans l'obscurité ici.

3
clockw0rk

Rien dans la documentation de GCC n'indique que GCC se comporterait différemment si son nom exécutable n'était pas gcc mais cc . Le GNU compilateur Fortran même le mentionne :

Une version de la commande gcc (qui peut également être installée en tant que commande cc du système)

2
lothar

"Non. GCC se comporte de la même manière, qu'il soit appelé via 'gcc' ou 'cc'."

[Cité dans le message d'origine.]

Sur la base de mon expérience dans Ubuntu 14.04, cela n'a pas été le cas.

Lorsque je compile mon programme en utilisant:

gcc -finstrument-functions test.c

Je n'obtiens aucun changement dans le comportement de mon code. Mais quand je compile en utilisant

cc -finstrument-functions test.c

Il se comporte différemment. (Dans les deux cas, j'ai incorporé les changements appropriés dans mon code décrit ici pour faire fonctionner -finstrument-functions).

2
plafratt

Étant donné que cela vient d'UNIX, je dirais que "cc" est le nom générique et "gcc" est le véritable compilateur. c'est-à-dire que "gcc" fournit "cc" de sorte qu'un programme recherchant "cc" trouverait et utiliserait "cc", ignorant béatement le véritable compilateur utilisé.

De plus, les programmes UNIX doivent ignorer le nom réel utilisé pour les appeler (pensez aux raccourcis de Windows Desktop - cela n'a pas de sens de vérifier comment le raccourci a été appelé), donc, non, "gcc" et "cc" font le même chose si "cc" est un lien vers "gcc".

À moins, bien sûr, que "cc" ne soit pas un lien symbolique mais un shellscript appelant gcc.

1
Alan Plum

Pour mon système d'exploitation (Ubuntu 14.04) cc ne permet pas la complétion des onglets, contrairement à gcc.

1
abcoep