Aufruf von GCC als “cc” im Vergleich zu “gcc”

Mir ist bewusst, dass GCC auf den meisten GNU/Linux-Systemen unter dem Namen „cc“ von der Befehlszeile aufgerufen werden kann (im Gegensatz zu „gcc“). Gibt es einen Unterschied im Verhalten von GCC, wenn es auf die eine oder andere Weise aufgerufen wird?

Ich weiß zum Beispiel, dass das Aufrufen von GCC über den Namen „g++“ anstelle von „gcc“ dazu führt, 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”?

BEARBEITEN: Keine der bisher eingegangenen Antworten gab a endgültig “ja” oder “nein”, ob sich GCC anders verhält, wenn es auf die eine oder andere Weise aufgerufen wird. Die Idee, in die Quelle einzutauchen, um ihr Verhalten zu überprüfen, führte mich jedoch auf diesen Weg. Basierend auf dem, was ich dort gefunden habe, glaube ich jetzt, dass die Antwort lautet:

Nein. GCC verhält sich gleich, egal ob es über “gcc” oder “cc” aufgerufen wird..

Zum Grinsen habe ich gerade nachgezeichnet, wie argv[0] wird innerhalb von gcc verwendet (main.c -> top_lev.c -> opts.c -> langhooks.c) und es scheint so argv[0] wird derzeit für nichts anderes als das Geben verwendet malloc etwas zu melden, wenn es fehlschlägt. Es scheint keine Verhaltensänderung zu geben, wenn argv[0] ist alles andere als gcc.

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

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

POSIX hat ein Dienstprogramm namens c99 was ich glaube, ist der Nachfolger von c89. Es sagt

Das Dienstprogramm c99 basiert auf dem Dienstprogramm c89, das ursprünglich im Standard ISO POSIX-2:1993 eingeführt wurde. Einige der Änderungen von c89 umfassen die Änderung des Inhalts des Abschnitts “Standardbibliotheken”, um neue Kopfzeilen und Optionen zu berücksichtigen; B. zum Operanden -l rt hinzugefügt, und der Trace-Operand -l für die Ablaufverfolgungsfunktionen hinzugefügt.

Ich bin mit all diesen verschiedenen Standards nicht wirklich vertraut, aber es sieht so aus, als ob das neuere SUSv3 (POSIX:2004) und die noch neuere POSIX:2008 (scheint noch keine SUS-Nummer zu haben) Geben Sie kein aufgerufenes Dienstprogramm an cc mehr, aber nur das Dienstprogramm genannt c99. Übrigens, mein Linux-System (Arch_Linux) enthält eine Manpage von c99 aber nicht c89enthält aber nur ein Dienstprogramm namens ccdoch keins c89 Noch c99. Viel Verwirrung drin 🙂

Auf meinem Mac aus man gcc:

In Apples Version von GCC sind sowohl cc als auch gcc eigentlich symbolische Links zu einem Compiler namens gcc-version. Ebenso sind c++ und g++ Links zu einem Compiler namens g++-version.

Basierend darauf würde ich annehmen, dass sich cc und gcc gleich verhalten.

Ich hatte heute die gleichen Zweifel und habe versucht, es selbst 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 Prinzip cc verweist auf gcc.

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

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

Beim Erstellen von zlib 1.2.5 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 Konfigurationsskript berücksichtigt nicht die Möglichkeit, dass cc auf einem Linux-System gcc sein könnte. Seien Sie also vorsichtig, wie weit Sie mit Ihren Annahmen gehen.

cc ist nur die UNIX-Art, den Compiler aufzurufen, er funktioniert auf allen Unices.

Dieser Thread ist vielleicht alt, aber ich möchte etwas hinzufügen (vielleicht findet ihn jemand in der Zukunft).

Wenn Sie dieses Programm kompiliert haben

#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 übergeben “AAAAAAAAAAAAAAAAAAAAAA” als Argument, es wird nicht in Puffer2 überlaufen, während es TUT, wenn Sie mit “cc” kompilieren, was für mich ein Hinweis darauf ist, dass Sie “gcc” verwenden, die Speicherverwaltung funktioniert anders, vielleicht durch Leerzeichen zwischen den Speichersegmenten der Felder buff1 & buff2 ?

Vielleicht kann hier jemand mit mehr Erfahrung Licht ins Dunkel bringen.