Мне известно, что в большинстве систем GNU/Linux GCC может быть вызвано именем "cc" из командной строки (в отличие от "gcc" ). Есть ли какая-либо разница в поведении GCC, когда он вызывается одним способом в сравнении с другим?
Например, я знаю, что вызов GCC с помощью имени "g++" вместо "gcc" заставляет GCC вести себя по-другому (он обрабатывает файлы .c в качестве источника и ссылок на С++ - в стандартной библиотеке С++). Есть ли аналогичная разница в поведении между "gcc" и "cc" ?
РЕДАКТИРОВАТЬ: Ни один из полученных ответов пока не дал окончательного "да" или "нет" относительно того, будет ли GCC вести себя по-другому, если он будет вызван в одну сторону по сравнению с другой. Однако идея, даваемая погружению в источник, чтобы проверить его поведение, ведет меня по этому пути. Основываясь на том, что я нашел там, теперь я верю, что ответ:
Нет. GCC ведет себя одинаково независимо от того, вызвана ли она через "gcc" или "cc" .
Для усмешек я просто проследил, как argv[0] используется из gcc (main.c → top_lev.c → opts.c → langhooks.c), и кажется, что argv[0] в настоящее время используется не что иное, как давать malloc что-то сообщить, когда он терпит неудачу. По-видимому, не наблюдается никакого изменения поведения, если argv[0] есть что-то другое, кроме 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 trace, добавленный для функций трассировки.
Я не очень хорошо знаком со всеми этими стандартами, но это похоже на более свежий SUSv3 (POSIX:2004) и но более поздний POSIX:2008 (пока, похоже, еще не имеет номера SUS), больше не указывайте утилиту с именем cc, но только утилита под названием c99. Кстати, моя Linux-система (Arch_Linux) содержит man-страницу c99, но не c89, но содержит только служебную программу cc, но ни c89, ни c99. Много путаницы там:)
На моем mac от man gcc:
В версии GCC от Apple, как cc, так и gcc - фактически символические ссылки на компилятор назван как gcc-версия. Аналогично, С++ и g++ являются ссылками на компилятор назван как g++ - версия.
Исходя из этого, я бы предположил, что 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.
Конфигурация script не учитывает возможность того, что 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;
}
с "gcc", и вы передаете его "AAAAAAAAAAAAAAAAAAAAAAAAA" в качестве аргумента, он не будет переполняться в buffer2, а если вы скомпилированы с "cc", для меня это намек на то, что если вы использовали "gcc", управление памятью работает по-разному, может быть, помещая пространство между сегментами памяти полей buff1 и buff2?
Может быть, кто-то с большим опытом может помещать свет в темноту.
Ничто в документации GCC не указывает на то, что GCC будет вести себя иначе, если его исполняемое имя не является gcc, но cc. Компилятор GNU Fortran даже упоминает, что:
Версия команды gcc (которая также может быть установлена как системная команда cc)
Я использую UNIX с 1983 года, а компилятор C тогда назывался cc. Приятно думать, что, возможно, makefile, который я написал, тогда мог бы по-прежнему работать над последним дистрибутивом Linux сегодня...
"Нет. GCC ведет себя одинаково независимо от того, вызвана ли она через 'gcc' или 'cc'."
[Цитата из исходного сообщения.]
Основываясь на моем опыте в Ubuntu 14.04, это не так.
Когда я скомпилирую свою программу, используя:
gcc -finstrument-functions test.c
Я не вижу никаких изменений в поведении моего кода. Но когда я компилирую с помощью
cc -finstrument-functions test.c
Это ведет себя по-другому. (В обоих случаях я включил соответствующие изменения в мой код, описанный здесь, чтобы работать -finstrument-функции).
Учитывая, что это происходит из UNIX, я бы сказал, что "cc" - это общее имя, а "gcc" - это фактический компилятор. то есть "gcc" предоставляет "cc" , поэтому программа, которая ищет "cc" , найдет и использует "cc" , блаженно игнорируя используемый фактический компилятор.
Кроме того, UNIX-программы должны быть не осведомлены о фактическом имени, используемом для их вызова (подумайте о ярлыках Windows Desktop - нет смысла проверять, что вызвал ярлык), поэтому нет, "gcc" и "cc" делайте то же самое, если "cc" - это ссылка на "gcc".
Если, конечно, "cc" не является символической ссылкой, а вызовом командной строки gcc.
Для моей ОС (Ubuntu 14.04) cc не разрешает выполнение табуляции, тогда как gcc делает.