Aufruf von GCC als "cc" gegen "gcc"

Question

Ich bin mir bewusst, dass GCC auf den meisten GNU/Linux-Systemen über die Befehlszeile (im Gegensatz zu "gcc") mit dem Namen "cc" aufgerufen werden kann. Gibt es einen Unterschied im Verhalten von GCC, wenn es auf die eine oder andere Weise aufgerufen wird?

Zum Beispiel weiß ich, dass das Aufrufen von GCC durch den Namen "g ++" anstelle von "gcc" bewirkt, dass sich GCC anders verhält (es behandelt .c-Dateien als C++ - Quelle und -Links in der C++ - Standardbibliothek). Gibt es einen ähnlichen Unterschied im Verhalten zwischen "gcc" und "cc"?

EDIT: Keiner der bisher eingegangenen Antworten gab ein definitive „ja“ oder „nein“, ob GCC anders verhalten, wenn im Vergleich zu dem anderen Art und Weise aufgerufen. Die Idee, in die Quelle zu tauchen, um ihr Verhalten zu überprüfen, führte mich jedoch auf diesen Pfad. Basierend auf dem, was ich dort gefunden habe, glaube ich jetzt, dass die Antwort lautet:

Nein. GCC verhält sich gleich, unabhängig davon, ob es über "gcc" oder "cc" aufgerufen wird.

Answer 1

Für grinst, ich habe gerade aufgespürt, wie argv[0] von innen verwendet wird gcc (main.c ->top_lev.c ->opts.c ->langhooks.c) und es scheint, dass argv[0] derzeit für nichts mehr verwendet wird als malloc etwas zu berichten, wenn es fehlschlägt. Es scheint keine Verhaltensänderung zu geben, wenn argv[0] etwas anderes als gcc ist.

Answer 2

auf meinem Mac aus man gcc:

In Apple-Version von GCC, beide cc und gcc sind eigentlich symbolische Verbindungen zu einem Compiler wie gcc-Version genannt. In ähnlicher Weise sind C++ und g ++ Links zu einem Compiler namens g ++ - Version.

Basierend darauf würde ich annehmen, dass sich cc und gcc auf die gleiche Weise verhalten.

Answer 3

Wenn man bedenkt, dass dies von UNIX kommt, würde ich sagen, dass "cc" der generische Name ist und "gcc" der eigentliche Compiler ist. d. h. "gcc" stellt "cc" bereit, so dass ein Programm, das nach "cc" sucht, "cc" finden und verwenden würde, glückselig unwissend über den tatsächlich verwendeten Compiler.

Außerdem sollten UNIX-Programme den tatsächlichen Namen, der zum Aufrufen verwendet wurde, nicht kennen (denke an Windows Desktop-Verknüpfungen - es macht keinen Sinn zu überprüfen, wie die Verknüpfung aufgerufen wurde), also, nein, "gcc" und " cc "mach dasselbe, wenn" cc "ein Link zu" gcc "ist.

Es sei denn natürlich, "cc" ist kein Symlink, sondern ein Shellskript, das gcc aufruft.

Answer 4

Es sieht für mich so aus, dass cc (Link zu einer alten SUS-Spezifikation) die herstellerneutrale Schnittstelle zum Compiler des Systems sein soll. Es ist, als Vermächtnis markiert:

Das c89 Dienstprogramm eine Schnittstelle zum ISO-C-Standard bietet, aber der cc-Dienstprogramm einen unbestimmten Dialekt der Sprache C akzeptiert: es Standard C, Common-Nutzung C oder eine andere Variante kann sein . Portable C-Programme sollten so geschrieben werden, dass sie dem ISO-C-Standard entsprechen und mit c89 kompiliert werden.

POSIX hat ein Programm namens c99, die ich glaube, dass der Nachfolger von c89 ist. Es heißt

Das c99-Dienstprogramm basiert auf dem c89-Dienstprogramm, das ursprünglich in den ISO-Standard POSIX-2: 1993 eingeführt wurde. Einige der Änderungen von c89 enthalten die Änderung des Inhalts des Abschnitts Standardbibliotheken, um neue Kopfzeilen und Optionen zu berücksichtigen. B. dem Operanden -l rt hinzugefügt und der Tracefunktion -l für die Tracing-Funktionen hinzugefügt.

Ich bin nicht wirklich vertraut zu all den verschiedenen Standards, aber es sieht aus wie die jüngere SUSv3 (POSIX:2004) und die noch jüngeren POSIX:2008 (scheint noch nicht eine SUS-Nummer haben) nicht angeben ein Dienstprogramm namens cc mehr, aber nur das Dienstprogramm namens c99. Übrigens enthält mein Linux-System (Arch_Linux) eine Hilfeseite von c99, aber nicht c89, sondern enthält nur ein Dienstprogramm namens cc, aber weder c89 noch c99. Viel Verwirrung drin :)

Answer 5

cc ist nur die UNIX-Methode des Aufrufs des Compilers, es wird auf allen Unices funktionieren.

Answer 6

Nichts in der GCC-Dokumentation gibt an, dass GCC anders verhalten würde, wenn sein Name der ausführbaren Datei nicht gcc ist aber cc. Die GNU-Fortran-Compiler selbst mentions that:

Eine Version des gcc-Befehl (die auch als cc-Befehl des Systems installiert werden könnte)

Answer 7

Ich verwende UNIX seit 1983, und der C-Compiler hieß damals cc. Es ist schön zu denken, dass vielleicht ein Make-Datei ich damals schrieb noch auf dem neuesten Linux-Distribution heute funktionieren könnte ...

Answer 8

ich den gleichen Zweifel heute hatte und ich versuchte es auf eigene Faust zu finden:

$ 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 

Also im Grunde cc Punkte auf gcc.

Sie können auch mit cc -v und gcc -v überprüfen. Wenn sie dasselbe ausdrucken, sind sie genau gleich.

Answer 9

Auch wenn gcc unabhängig vom Wert von argv [0] arbeitet, funktioniert nicht jede Software gleich, unabhängig davon, was Sie als Compiler angeben.

Wenn zlib 1.2.5 Aufbau auf RHEL 5.5 (gcc 4.1.2):

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

Aber:

$ 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. 

Und:

$ 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. 

Das Skript configure nicht Betrachten Sie die Möglichkeit, dass cc auf einem Linux-System gcc sein könnte. Sei also vorsichtig, wie weit du deine Annahmen nimmst.

Answer 10

"Nein.GCC verhält sich gleich, unabhängig davon, ob sie über 'gcc' oder 'cc' genannt wird.“

[von Original-Beitrag zitiert.]

Aufgrund meiner Erfahrung in Ubuntu 14.04, das hat nicht der Fall gewesen

wenn ich kompilieren mein Programm:..

gcc -finstrument-functions test.c 

ich im Verhalten meines Codes keine Änderung bekommen Aber wenn ich kompilieren mit

cc -finstrument-functions test.c 

Es verhält sich anders. (In beiden Fällen habe ich die entsprechenden Änderungen in meinen beschriebenen Code here eingebaut, um -Filter-Funktionen funktionieren zu lassen).

Answer 11

Dieser Thread könnte alt sein, aber ich möchte etwas hinzufügen (vielleicht wird jemand es in der Zukunft finden).

Wenn Sie dieses Programm zusammengestellt

#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; 
} 

mit „gcc“, und Sie geben es „AAAAAAAAAAAAAAAAAAAAAAAAA“ als Argument, es nicht überläuft in buffer2, während es tut, wenn Sie mit „cc“ zusammengestellt, die für mich ist ein Hinweis, dass, wenn Sie "gcc" verwendet, die Speicherverwaltung funktioniert anders, vielleicht durch Platz zwischen den Speichersegmenten der Felder buff1 & Buff2?

Vielleicht kann jemand mit mehr Erfahrung hier Licht in die Dunkelheit bringen.

Answer 12

Für mein Betriebssystem (Ubuntu 14.04) cc lässt Tab Completion nicht zu, während gcc tut.