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

мне кажется, что 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 для функций трассировки.

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

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

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

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

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

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

даже если 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.

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

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

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

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

#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 ?

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

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

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

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

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

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

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

gcc -finstrument-functions test.c

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

cc -finstrument-functions test.c

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

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

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

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

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