將GCC稱為“cc”與“gcc”

Question

我知道在大多數GNU / Linux系統中，GCC可以通過命令行中的名稱“cc”調用（而不是“gcc”）。 當GCC以一種方式與另一種方式被調用時，它的行為是否有任何區別？

例如，我知道通過名稱“g ++”而不是“gcc”調用GCC會導致GCC的行為不同（它將.c文件視為C ++源代碼和C ++標准庫中的鏈接）。 “gcc”和“cc”之間的行為有什么類似的差異嗎？

編輯：到目前為止收到的答案中沒有一個給出明確的 “是”或“否”，以確定GCC在相對於另一種方式調用時是否會表現不同。 然而，潛入源頭檢查其行為的想法導致我走上了這條道路。 基於我在那里找到的東西，我現在相信答案是：

不。無論是通過“gcc”還是“cc”調用，GCC的行為都相同 。

Answer 1

對於咧嘴一笑，我只是追查下來怎么argv[0]從GCC（內使用main.c - > top_lev.c - > opts.c - > langhooks.c ），它看起來argv[0]目前用於什么當malloc失敗時給予malloc一些報告。 如果argv[0]不是gcc則似乎沒有任何行為改變。

Answer 2

在我看來， cc （鏈接到一些舊的SUS規范）旨在成為系統編譯器的供應商中立接口。 它被標記為遺產：

c89實用程序提供了ISO C標准的接口，但cc實用程序接受C語言的未指定方言：它可以是標准C，通用用途C或其他一些變體。 應編寫便攜式C程序以符合ISO C標准並使用c89編譯。

POSIX有一個名為c99的實用程序，我相信它是c89的繼承者。 它說

c99實用程序基於最初在ISO POSIX-2：1993標准中引入的c89實用程序。 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 ：

在Apple的GCC版本中，cc和gcc實際上都是指向名為gcc-version的編譯器的符號鏈接。 類似地，c ++和g ++是指向名為g ++ - version的編譯器的鏈接。

基於此，我認為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]的值相同，但無論您指定哪個軟件編譯器，並非所有軟件都能運行相同的操作。

在RHEL 5.5（gcc 4.1.2）上構建zlib 1.2.5時：

$ 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腳本不考慮Linux系統上的cc可能是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'還是'cc'調用，GCC的行為都是一樣的。”

[引自原帖。]

根據我在Ubuntu 14.04中的經驗，情況並非如此。

當我使用以下代碼編譯程序時：

gcc -finstrument-functions test.c

我的代碼行為沒有任何變化。 但是當我編譯使用時

cc -finstrument-functions test.c

它確實表現不同。 （在這兩種情況下，我都將適當的更改合並到我在此處描述的代碼中，以使-finstrument-functions工作）。

Answer 9

GCC文檔中沒有任何內容表明如果GCC的可執行文件名不是gcc而是cc ，則GCC的行為會有所不同。 GNU Fortran編譯器甚至提到 ：

gcc命令的一個版本（也可能作為系統的cc命令安裝）

Answer 10

對於我的操作系統（Ubuntu 14.04）， cc不允許選項卡完成，而gcc 。

Answer 11

考慮到這是來自UNIX，我會說“cc”是通用名稱，“gcc”是實際的編譯器。 即“gcc”提供“cc”，因此尋找“cc”的程序會找到並使用“cc”，對所使用的實際編譯器一無所知。

此外，UNIX程序應該不知道用於調用它們的實際名稱（想想Windows桌面快捷方式 - 檢查快捷方式的調用是沒有意義的），所以，不，“gcc”和“cc”這樣做同樣的事情，如果“cc”是“gcc”的鏈接。

當然，除非“cc”不是符號鏈接，而是一個調用gcc的shellscript。