Вызов GCC как «cc» вместо «gcc»
https://stackoverflow.com/questions/939989
-
06-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я знаю, что в большинстве систем GNU/Linux GCC можно вызвать из командной строки по имени «cc» (в отличие от «gcc»).Есть ли какая-либо разница в поведении GCC, когда он вызывается одним способом или другим?
Например, я знаю, что вызов GCC через имя «g++» вместо «gcc» приводит к тому, что GCC ведет себя по-другому (он рассматривает файлы .c как источник C++, а ссылки — в стандартной библиотеке 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 трассировки, добавленному для функций трассировки.
Я не совсем знаком со всеми этими различными стандартами, но похоже, что это более поздний SUSv3 (ПОСИКС:2004) и еще более поздний ПОСИКС:2008 (похоже, еще не имеет номера SUS) не указывайте утилиту под названием cc больше, но только утилита под названием c99.Кстати, моя система Linux (Arch_Linux) содержит справочную страницу c99 но нет c89, но содержит только утилиту под названием cc, но ни c89 ни c99.Там большая путаница :)
На моем Mac от man gcc:
В версии GCC от Apple как CC, так и GCC на самом деле являются символическими ссылками на компилятор, названный как GCC-версия.Точно так же C ++ и 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.
Сценарий настройки не учитывает возможность того, что cc в системе Linux может быть gcc.Поэтому будьте осторожны, насколько далеко вы заходите в своих предположениях.
cc — это просто способ вызова компилятора в UNIX, он будет работать на всех Unix.
Эта ветка может быть старой, но я хочу что -то добавить в нее (возможно, кто -то найдет это в будущем).
Если вы скомпилировали эту программу
#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», и вы передаете его «ААААААААААААААААААА» в качестве аргумента, он не будет переполняться в буфер 2, хотя это ДЕЛАЕТ, если вы скомпилировали с «cc», что для меня является подсказкой, что если вы использовали «gcc», управление памятью работает по-другому, возможно, помещая пространство между сегментами памяти полей buff1 и buff2 ?
Возможно, кто-то более опытный сможет пролить здесь свет на тьму.
Ничто в документации GCC не указывает на то, что GCC будет вести себя иначе, если имя его исполняемого файла не GCC но копия.Даже компилятор GNU Fortran упоминает, что:
Версия команды gcc (которая также может быть установлена как системная команда cc).
"Нет.GCC ведет себя так же независимо от того, называется ли он через «GCC» или «CC».
[Цитата из оригинального сообщения.]
Судя по моему опыту работы с Ubuntu 14.04, это не так.
Когда я компилирую свою программу, используя:
gcc -finstrument-functions test.c
Я не получаю никаких изменений в поведении моего кода.Но когда я компилирую, используя
cc -finstrument-functions test.c
Он ведет себя по-другому.(В обоих случаях я внес соответствующие изменения в свой код, описанный здесь чтобы заставить -finstrument-functions работать).
Учитывая, что это происходит из UNIX, я бы сказал, что «cc» — это общее имя, а «gcc» — это фактический компилятор.то есть«gcc» предоставляет «cc», поэтому программа, ищущая «cc», найдет и использует «cc», в блаженном неведении относительно фактического используемого компилятора.
Кроме того, программы UNIX не должны знать фактическое имя, используемое для их вызова (вспомните ярлыки на рабочем столе Windows — нет смысла проверять, как был вызван ярлык), поэтому нет, «gcc» и «cc» делают все необходимое. то же самое, если «cc» является ссылкой на «gcc».
Если, конечно, «cc» — это не символическая ссылка, а скрипт, вызывающий gcc.
Для моей ОС (Ubuntu 14.04) cc не позволяет завершить табуляцию, тогда как gcc делает.
