Invocando GCC como “cc” versus “gcc”
https://stackoverflow.com/questions/939989
-
06-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Estou ciente de que na maioria dos sistemas GNU / Linux, GCC pode ser chamado pelo nome de "cc" na linha de comando (em oposição a "gcc"). Existe alguma diferença no comportamento do GCC quando é invocada uma forma contra o outro?
Por exemplo, eu sei que a invocação GCC através do nome "g ++" em vez de "gcc" provoca GCC se comportar de forma diferente (ele trata arquivos .c como fonte e ligações-no C ++ biblioteca padrão C ++). Existe alguma diferença semelhante de comportamento entre "gcc" versus "cc"?
EDIT: Nenhuma das respostas recebidas até agora deu um definitiva "sim" ou "não" sobre se GCC irá se comportar de maneira diferente se forma um invocado contra o outro . No entanto, a idéia dado a mergulhar na fonte para verificar seu comportamento me levam por esse caminho. Baseado no que eu encontrei lá, agora eu acredito que a resposta é:
Nenhum. GCC se comporta da mesma, independentemente de ela é chamada através de "gcc" ou "cc" .
Solução
Para sorrisos, eu só rastreada para baixo como argv[0] é usado de dentro gcc ( main.c -> top_lev.c -> opts.c -> langhooks.c) e parece que argv[0] é atualmente usado para nada mais do que dar malloc algo para relatório quando ele falhar. Não parece haver qualquer mudança de comportamento se argv[0] é outra coisa senão gcc.
Outras dicas
Parece-me que cc (link para alguma especificação SUS velho ) destina-se a ser a interface vendor-neutral para compilador do sistema. É marcado como legado:
O utilitário c89 fornece uma interface para o padrão ISO C, mas a utilidade cc aceita um dialeto não especificado da linguagem C: pode ser padrão C,-uso comum C ou qualquer outra variante. programas em C portáteis devem ser escritos em conformidade com o padrão ISO C e compilado com c89.
POSIX tem um utilitário chamado c99 que eu acredito que é a sucessor de c89. Diz
O utilitário c99 baseia-se na utilidade c89 originalmente introduzido na ISO POSIX-2: 1993 padrão. Algumas das mudanças de c89 incluem a modificação do conteúdo da seção de bibliotecas padrão para a conta para novos cabeçalhos e opções; por exemplo, adicionado ao ta -l operando, e o traço -l operando adicionado para as funções de Trace.
Eu não sou muito familiarizado com todos esses diferentes padrões, mas parece que o SUSv3 mais recente ( POSIX: 2004 ) eo POSIX ainda mais recente: 2008 (não parece ter um número SUS ainda) não especificam um utilitário chamado cc mais, mas apenas o utilitário chamado c99. Aliás, o meu sistema Linux ( Arch_Linux ) contém uma página de manual de c99 mas não c89, mas contém apenas um utilitário chamado cc, mas nem c89 nem c99. Muita confusão lá:)
No meu mac de man gcc:
versão do GCC de em Apple, tanto cc e gcc são links realmente simbólicos para um compilador nomeado como gcc-versão. Do mesmo modo, c ++ ++ e g são links para uma compilador nomeado como g ++ -. versão
Com base no que eu diria que cc e gcc se comportam da mesma maneira.
Eu tive a mesma dúvida hoje e eu tentei encontrá-lo em meu próprio:
$ 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
Então, basicamente cc aponta para gcc.
Você também pode verificar usando cc -v e gcc -v. Se imprimir a mesma coisa, isso significa que eles são exatamente os mesmos.
Mesmo se gcc funciona da mesma independente de argv [0] value 's, nem todo o software irá operar o mesmo, independentemente do que você especificar como o compilador.
Ao construir zlib 1.2.5 no RHEL 5.5 (gcc 4.1.2):
$ md5sum $(which cc)
69a67d3029b8ad50d41abab8d778e799 /usr/bin/cc
$ md5sum $(which gcc)
69a67d3029b8ad50d41abab8d778e799 /usr/bin/gcc
Mas:
$ 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.
E:
$ 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.
O script configure não considera a possibilidade de que cc em um sistema Linux pode ser gcc. Então, cuidado quão longe você tirar suas suposições.
cc é apenas a maneira UNIX de chamar o compilador, ele irá funcionar em todos os Unices.
este segmento pode ser velho, mas eu quero acrescentar algo a ele (Talvez alguém vai encontrá-lo no futuro).
Se você compilou 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;
}
com "gcc", e você passá-lo "AAAAAAAAAAAAAAAAAAAAAAAAA" como argumento, não vai transbordar em buffer2, enquanto ele faz se você compilado com "cc", o que para mim é um indício de que se você usou "gcc", o gerenciamento de memória funciona diferente, talvez, colocando espaço entre os segmentos de memória dos campos Buff1 & buff2?
Talvez alguém com mais experiance pode colocar luz na escuridão aqui.
Nada na documentação do GCC indica que GCC iria se comportar de forma diferente se o seu nome executável não é gcc e cc . O compilador GNU Fortran mesmo menciona que :
A versão do comando gcc (que também pode ser instalado como comando cc do sistema)
"Não. GCC se comporta da mesma, independentemente de ele é chamado via 'gcc' ou "cc ".
[Citado do post original.]
Com base na minha experiente no Ubuntu 14.04, este não foi o caso.
Quando eu compilar meu programa usando:
gcc -finstrument-functions test.c
Eu não obter qualquer mudança no comportamento do meu código. Mas quando eu compilar usando
cc -finstrument-functions test.c
Ele se comporta de forma diferente. (Em ambos os casos, eu incorporou as alterações apropriadas em meu código descrito href="http://codingrelic.geekhold.com/2010/09/gcc-function-instrumentation.html" aqui para fazer -finstrument-funções de trabalho).
Considerando este é proveniente de UNIX, eu diria que "cc" é o nome genérico e "gcc" é o compilador real. ou seja, "gcc" fornece "cc" para um programa de procura de "cc" iria encontrar e usar "cc", alegremente ignorante do compilador real que está sendo usado.
Além disso, programas de UNIX deve ser ignorante do nome real usado para chamá-los (acho que o Windows desktop atalhos - isso não faz sentido para verificar o que o atalho foi chamado), então, não "gcc" e "cc "fazer a mesma coisa se "cc" é um link para "gcc".
A menos, claro, "cc" não é um link simbólico, mas um chamado gcc shellscript.
Para o meu SO (Ubuntu 14.04) cc não permite a conclusão de tabulação, enquanto gcc faz.
