将GCC分别称为“ cc”和“ gcc”

我知道在大多数GNU / Linux系统上，可以从命令行通过名称“ cc”（而不是“ gcc”）调用GCC。一种方式与另一种方式调用时，GCC的行为是否有差异？

例如，我知道通过名称“ g ++”而不是“ gcc”调用GCC会导致GCC行为不同（它将.c文件视为C ++源代码，并在C ++标准库中链接）。“ gcc”与“ cc”之间在行为上是否有类似的区别？

编辑：到目前为止，关于GCC如果以一种方式调用还是以另一种方式调用，行为是否有所不同，到目前为止，没有一个答案给出明确的“是”或“否”。但是，提出深入研究源代码以检查其行为的想法使我沿着这条路走了。根据我在那里的发现，我现在认为答案是：

否。无论通过“ gcc”还是“ cc”调用，GCC的行为都相同。

对于咧嘴笑，我只是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语言方言：它可以是Standard 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。那里很混乱:)

在我的Mac上，来自man gcc：

在Apple版本的GCC中，cc和gcc实际上都是指向名为gcc-version之类的编译器的符号链接。同样，c ++和g ++是指向名为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]的值无关，无论您指定哪个编译器，并非所有软件都将操作相同。

在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的可能性。因此，请谨慎对待假设。

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”，然后将其传递给“ AAAAAAAAAAAAAAAAAAAAAAAAAAAA”作为参数，它将不会溢出到buffer2中，而如果使用“ cc”进行编译则不会溢出，这对我来说是一个提示，如果您使用“ gcc”，则表示内存管理可能通过在字段buff1和buff2的内存段之间放置空间来实现不同的工作？

也许更有经验的人可以将光明带入这里的黑暗中。

GCC文档中没有任何内容表明，如果GCC的可执行文件名称不是gcc而是cc，则GCC的行为将有所不同。GNU Fortran编译器甚至提到：

gcc命令的版本（也可以作为系统的cc命令安装）

“不会。无论是通过'gcc'还是'cc'调用，GCC的行为都相同。”

[引自原始帖子。]

根据我在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的shellscript。

对于我的操作系统（Ubuntu 14.04）cc，不允许制表符完成，而允许gcc。