Invocar a GCC como "cc" frente a "gcc"

download gcc linux

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 fuentes y enlaces de C ++, en la biblioteca estándar de C ++). ¿Hay alguna diferencia similar en el comportamiento entre "gcc" versus "cc"?

EDITAR: Ninguna de las respuestas recibidas hasta ahora dio un "sí" o un "no" definitivo en cuanto a si GCC se comportará de manera diferente si se invoca de una manera contra 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

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

[Citado de la publicación original.]

Basado en mi experiencia en Ubuntu 14.04, este no ha sido el caso.

Cuando compilo mi programa usando:

gcc -finstrument-functions test.c

No obtengo 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 que funcionen las funciones -finstrument-functions).

Answer 2

En mi mac desde man gcc :

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

Basado en eso, supongo que cc y gcc se comportan de la misma manera.

Answer 3

Hoy tuve la misma duda y traté de encontrarla 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

Entonces, básicamente, cc apunta a gcc .

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

Answer 4

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

Al compilar 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 considera 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 5

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 especificado del lenguaje C: puede ser el estándar C, el uso común 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 la sucesora de c89 . Dice

La utilidad c99 se basa en la utilidad c89 originalmente introducida 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 dar cuenta de 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 familiarizado con todos esos estándares diferentes, pero parece que el SUSv3 ( POSIX:2004 ) más reciente y el POSIX:2008 más reciente (no parece tener un número SUS todavía) no especifican una utilidad ya se llamaba cc , pero solo la utilidad se llama c99 . A propósito, mi sistema Linux ( Arch_Linux ) contiene una página de manual de c99 pero no de c89 , pero solo contiene una utilidad llamada cc , pero ni c89 ni c99 . Mucha confusión allí :)

Answer 6

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

Una versión del comando gcc (que también podría instalarse como el comando cc del sistema)

Answer 7

Para mi sistema operativo (Ubuntu 14.04) cc no permite la finalización de pestañas, mientras que gcc sí.

Answer 8

Teniendo en cuenta 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 use "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 acceso directo), entonces, no, "gcc" y "cc" hacen lo 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 9

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

Answer 10

este hilo puede ser antiguo, pero quiero agregarle algo (quizás 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 le pasa "AAAAAAAAAAAAAAAAAAAAAAAAA" como argumento, no se desbordará en buffer2, mientras que SI HIZO si compiló con "cc", que para mí es una pista de que si usó "gcc", la gestión de memoria funciona de manera diferente, tal vez poniendo espacio entre los segmentos de memoria de los campos buff1 y buff2?

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

Answer 11

Para sonreír, simplemente argv[0] cómo se usa argv[0] desde dentro de gcc ( main.c -> top_lev.c -> opts.c -> langhooks.c ) y parece que argv[0] se usa actualmente para nada más que darle a malloc algo que informar cuando falla. No parece haber ningún cambio de comportamiento si argv[0] es algo distinto de gcc .