Вызов GCC как " cc "против" gcc"

Я знаю, что в большинстве систем GNU/Linux GCC может быть вызван именем "cc" из командной строки (в отличие от "gcc"). Есть ли разница в поведении GCC, когда он вызывается одним способом против другого?

например, я знаю, что вызов GCC через имя " g++ "вместо" gcc " заставляет GCC вести себя по-разному (он обрабатывает .c файлы как источник C++ и ссылки - в стандартной библиотеке C++). Есть ли разница в поведении между "ССЗ" против "cc"?

EDIT: ни один из ответов, полученных до сих пор не дал окончательно "да" или " нет " относительно того, будет ли GCC вести себя по-разному, если вызывается одним способом против другого. Однако идея погрузиться в источник, чтобы проверить его поведение, ведет меня по этому пути. Основываясь на том, что я нашел там, я теперь считаю, что ответ:

нет. GCC ведет себя одинаково независимо от того, вызывается ли он через "gcc"или " cc".

67
c compiler-construction gcc gnu linux

11 ответов

для усмешки, я просто проследил, как argv[0] используется из gcc (main.c ->top_lev.c ->opts.c ->langhooks.c) и кажется, что argv[0] в настоящее время используется только для предоставления malloc что-то сообщить, когда он терпит неудачу. Кажется, что нет никакого изменения поведения, если argv[0] не gcc.

35

мне кажется, что cc (ссылка на некоторую старую спецификацию SUS)предназначена для нейтрального к поставщику интерфейса к компилятору системы. Он помечен как устаревший:

утилита c89 предоставляет интерфейс к стандарту ISO C, но утилита cc принимает неуказанный диалект языка C: это может быть стандартный C, общее использование C или какой-либо другой вариант. Портативные программы C должны быть написаны в соответствии со стандартом ISO C и скомпилированы с c89.

POSIX имеет утилиту под названием c99 который, я полагаю, является преемником c89. Тут написано

утилита c99 основана на утилите c89, первоначально представленной в стандарте ISO POSIX-2:1993. Некоторые из изменений c89 включают изменение содержимого раздела стандартные библиотеки для учета новых заголовков и параметров; например, добавлен в-L rt операнд и-l trace операнд добавлен для функций трассировки.

Я не очень знаком со всеми этими различными стандартами, но похоже, что более поздний SUSv3 (POSIX: 2004) и еще более поздние POSIX: 2008 (кажется, еще нет номера SUS) не указывайте утилиту под названием cc больше, но только утилита называется c99. Кстати, моя система Linux (Arch_Linux) содержит manpage c99 а не c89, но содержит только утилита называется cc, но ни c89, ни c99. Много путаницы там :)

14

на моем mac от man gcc:

в версии GCC от Apple, как cc, так и gcc фактически являются символическими ссылками на компилятор с именем gcc-version. Аналогично, C++ и G++ и ссылки на компилятор с именем g++ - version.

исходя из этого, я бы предположил, что cc и gcc ведут себя одинаково.

12

у меня было такое же сомнение сегодня, и я попытался найти его самостоятельно:

$ 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

Итак,cc указывает на gcc.

вы также можете проверить с помощью cc -v и gcc -v. Если они печатают одно и то же, это означает, что они точно такие же.

8

даже если gcc работает независимо от значения argv[0], не все программное обеспечение будет работать одинаково независимо от того, что вы указываете в качестве компилятора.

при построении zlib 1.2.5 на RHEL 5.5 (gcc 4.1.2):

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

но:

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

и:

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

сценарий configure не учитывает возможность того, что cc в системе Linux может быть gcc. Поэтому будьте осторожны в своих предположениях.

7

cc-это просто UNIX-способ вызова компилятора, он будет работать на всех Unices.

3

этот поток может быть старым, но я хочу добавить к нему что-то (возможно кто-то найдет его в будущем).

Если вы скомпилировали эту программу

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

с "ССЗ", и вы передаете его "ААААААААААААААААААААААААА" в качестве аргумента, это будет не переполнения в buffer2, пока это не произойдет, если вы скомпилировали с "CC", что для меня это намек на то, что если вы использовали "ССЗ", управления памятью по-другому, может, поставив пробел между памятью сегментов поля buff1 & buff2 ?

может быть, кто-то с большим опытом может поставить свет в темноте.

3

ничто в документации GCC не указывает, что GCC будет вести себя по-другому, если его исполняемое имя не gcc но cc. Компилятор GNU Fortran даже отмечает, что:

версия команды gcc (которая также может быть установлена как команда cc системы)

2

"нет. GCC ведет себя одинаково независимо от того, вызывается ли он через 'gcc' или "СС"."

[цитата из исходного поста.]

основываясь на моем опыте работы в Ubuntu 14.04, это не так.

когда я компилирую свою программу, используя:

gcc -finstrument-functions test.c

Я не получаю никаких изменений в поведении моего кода. Но когда я компилирую с помощью

cc -finstrument-functions test.c

он ведет себя по-другому. (В обоих случаях я включил соответствующие изменения в моем коде описаны здесь сделать -finstrument-функций работы).

2

учитывая, что это исходит из UNIX, я бы сказал, что "cc" - это общее имя, а "gcc" - фактический компилятор. т. е. " gcc "предоставляет " cc", поэтому программа, ищущая" cc", найдет и использует" cc", блаженно не зная о фактическом используемом компиляторе.

кроме того, программы UNIX должны быть не осведомлены о фактическом имени, используемом для их вызова (думаю, ярлыки на рабочем столе Windows - не имеет смысла проверять, что ярлык был вызван), поэтому нет, " gcc " и " cc "делают то же самое, если "cc" является ссылка на "ГХК".

Если, конечно, " cc " не является символической ссылкой, а shellscript, вызывающим gcc.

1

для моей ОС (Ubuntu 14.04) cc не позволяет завершить вкладку, тогда как gcc делает.

1