Подтвердить что ты не робот

Вызов GCC как "cc" по сравнению с "gcc"

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

Ответ 2

Мне кажется, что 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) содержит man-страницу c99, но не c89, но содержит только служебную программу cc, но ни c89, ни c99. Много путаницы там:)

Ответ 3

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

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

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

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

Ответ 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.

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

Ответ 6

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

Ответ 7

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

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

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

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

Ответ 8

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

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

Ответ 9

Я использую UNIX с 1983 года, а компилятор C тогда назывался cc. Приятно думать, что, возможно, makefile, который я написал, тогда мог бы по-прежнему работать над последним дистрибутивом Linux сегодня...

Ответ 10

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

[Цитата из исходного сообщения.]

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

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

gcc -finstrument-functions test.c

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

cc -finstrument-functions test.c

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

Ответ 11

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

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

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

Ответ 12

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