Invocando a GCC como "cc" frente a "gcc"

Question

Soy consciente de que en la mayoría de los sistemas GNU/Linux, GCC puede invocarse con el nombre "cc" desde la línea de comandos (en lugar de "gcc"). ¿Hay alguna diferencia en el comportamiento de GCC cuando se invoca de una manera contra la otra?

Por ejemplo, sé que invocar GCC con el nombre "g ++" en lugar de "gcc" hace que GCC se comporte de manera diferente (trata los archivos .c como fuente C++ y enlaces en la biblioteca estándar de C++). ¿Hay alguna diferencia similar en el comportamiento entre "gcc" versus "cc"?

EDIT: Ninguna de las respuestas recibidas hasta ahora dio un definitivo "sí" o "no" en cuanto a si GCC se comportará de manera diferente si se invoca una manera frente a la otra. Sin embargo, la idea de sumergirse en la fuente para verificar su comportamiento me lleva por ese camino. En base a lo que encontré allí, ahora creo que la respuesta es:

No. GCC se comporta igual independientemente de si se llama a través de "gcc" o "cc".

Answer 1

para las muecas, acabo rastreada cómo argv[0] se utiliza desde dentro gcc (main.c ->top_lev.c ->opts.c ->langhooks.c) y parece que argv[0] se utiliza actualmente para nada más que dar malloc algo que informar cuando falla. No parece haber ningún cambio de comportamiento si argv[0] es distinto de gcc.

Answer 2

en mi Mac de man gcc:

En la versión de Apple de GCC, tanto cc y gcc en realidad son enlaces simbólicos a un compilador nombrado como gcc-version. Del mismo modo, C++ y g ++ son enlaces a un compilador llamado como g ++ - versión.

En base a eso, supongo que cc y gcc se comportan de la misma manera.

Answer 3

Considerando que esto viene de UNIX, diría que "cc" es el nombre genérico y "gcc" es el compilador real. es decir, "gcc" proporciona "cc" para que un programa que busca "cc" encuentre y utilice "cc", felizmente ignorante del compilador real que se está utilizando.

Además, los programas de UNIX deben ignorar el nombre real utilizado para llamarlos (piense en los accesos directos de Windows Desktop - no tiene sentido comprobar cómo se llamaba el atajo), entonces, no, "gcc" y " cc "haga lo mismo si" cc "es un enlace a" gcc ".

A menos que, por supuesto, "cc" no sea un enlace simbólico sino un shellscript que llame a gcc.

Answer 4

Me parece que cc (enlace a alguna antigua especificación SUS) pretende ser la interfaz neutral del proveedor para el compilador del sistema. Está marcado como legado:

La utilidad C89 proporciona una interfaz para el estándar ISO C, pero la utilidad cc acepta un dialecto no especificada del lenguaje C: puede ser estándar C, común en el uso C o alguna otra variante . Los programas portátiles C deben escribirse para cumplir con el estándar ISO C y compilarse con c89.

POSIX tiene una utilidad llamada c99 que creo que es el sucesor de c89. Dice

La utilidad c99 se basa en la utilidad c89 presentada originalmente en el estándar ISO POSIX-2: 1993. Algunos de los cambios de c89 incluyen la modificación de los contenidos de la sección Bibliotecas estándar para tener en cuenta nuevos encabezados y opciones; por ejemplo, agregado al operando -l rt, y el operando de rastreo -l agregado para las funciones de rastreo.

No estoy muy familiarizado con todas esas diferentes normas, pero parece que la más reciente SUSv3 (POSIX:2004) y el aún más reciente POSIX:2008 (no parece tener un número SUS todavía) no especifican una utilidad llamada cc, pero solo la utilidad llamada c99. Por cierto, mi sistema Linux (Arch_Linux) contiene una página de manual de c99 pero no c89, pero solo contiene una utilidad llamada cc, pero ni c89 ni c99. Mucha confusión allí :)

Answer 5

cc es solo la forma UNIX de llamar al compilador, funcionará en todos los Unices.

Answer 6

Nada en la documentación de GCC GCC indica que se comportaría de forma diferente si su nombre ejecutable no es gcc pero cc. El compilador GNU Fortran incluso mentions that:

Una versión del comando gcc (que también podría ser instalado como comando de cc del sistema)

Answer 7

He estado usando UNIX desde 1983, y el compilador de C en aquel entonces se llamaba cc. Es bueno pensar que tal vez un makefile que escribí en aquel entonces todavía podía trabajar en la última distribución de Linux hoy ...

Answer 8

que tenían la misma duda hoy y tratado de encontrar por mi cuenta:

$ 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 

Por lo tanto, básicamente cc apunta a gcc.

También puede marcar usando cc -v y gcc -v. Si imprimen lo mismo, eso significa que son exactamente iguales.

Answer 9

Incluso si gcc opera de la misma manera independiente del valor de argv [0], no todo el software funcionará igual independientemente de lo que especifique como compilador.

Cuando la construcción de zlib 1.2.5 en RHEL 5.5 (gcc 4.1.2):

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

Pero:

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

Y:

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

El script de configuración no lo hace considere la posibilidad de que cc en un sistema Linux pueda ser gcc. Por lo tanto, tenga cuidado de cuán lejos toma sus suposiciones.

Answer 10

"No.GCC se comporta de la misma, independientemente de si se llama a través de 'gcc' o 'CC'."

[Citado de post original.]

Con base en mi experiencia en Ubuntu 14.04, esto no tiene ha sido el caso

cuando puedo compilar mi programa usando:..

gcc -finstrument-functions test.c 

que no reciben ningún cambio en el comportamiento de mi código, pero cuando compilo usando

cc -finstrument-functions test.c 

Se comporta de manera diferente. (En ambos casos, incorporé los cambios apropiados en mi código descrito here para hacer funcionar las funciones -finstrument-functions).

Answer 11

este hilo puede ser antiguo pero quiero agregarle algo (tal vez alguien lo encuentre en el futuro).

Si compiló este programa

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

con "gcc", y se le pasa "AAAAAAAAAAAAAAAAAAAAAAAAA" como argumento, no lo hará desbordamiento en tampón 2, mientras que lo hace cuando se ha compilado con "cc", que para mí es una pista de que si usaste "gcc", la gestión de memoria funciona de manera diferente, tal vez poniendo espacio entre los segmentos de memoria de los campos buff1 & buff2?

Tal vez alguien con más experiencia pueda iluminar la oscuridad aquí.

Answer 12

Para mi sistema operativo (Ubuntu 14.04) cc no permite la terminación de pestañas, mientras que gcc lo hace.