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

Question

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

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

РЕДАКТИРОВАТЬ: Ни один из полученных ответов пока что не дал окончательного"да" или "нет" относительно того, будет ли GCC вести себя по-разному, если вызывается так или иначе. Однако идея погрузиться в источник, чтобы проверить его поведение, привела меня на этот путь. Основываясь на том, что я нашел там, я теперь считаю, что ответ:

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

Answer 1

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

Answer 2

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

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

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

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

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

Answer 3

На моем Mac от man gcc:

В версии GCC от Apple, как cc, так и GCC на самом деле являются символическими ссылками на Компилятор назван как GCC-версия. Аналогично, c ++ и g ++ являются ссылками на Компилятор назван как g ++ - версия.

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

Answer 4

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

$ 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. Если они распечатывают одно и то же, это означает, что они точно такие же.

Answer 5

Даже если 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. Поэтому будьте осторожны, насколько далеко вы принимаете свои предположения.

Answer 6

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

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

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

с "gcc", и вы передаете его "AAAAAAAAAAAAAAAAAAAAAAAAA" в качестве аргумента, он не будет переполнен в buffer2, в то время как это происходит, если вы скомпилировали с "cc", что для меня является подсказкой, что если вы использовали "gcc" управление памятью работает по-другому, возможно, помещая пространство между сегментами памяти полей buff1 и buff2?

Может быть, кто-то с большим опытом может осветить тьму здесь.

Answer 7

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

Answer 8

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

[Цитата из оригинального сообщения.]

Судя по моему опыту в Ubuntu 14.04, этого не произошло.

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

gcc -finstrument-functions test.c

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

cc -finstrument-functions test.c

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

Answer 9

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

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

Answer 10

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