将 GCC 作为“cc”调用 与“gcc”相比

Question

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

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

编辑：到目前为止收到的答案都没有给出“是”或“否”的“肯定”或“否”来说明如果以一种方式调用 GCC 与另一种方式调用时 GCC 的行为是否会有所不同。 然而，深入研究源代码以检查其行为的想法引导我走上了这条道路。 根据我在那里的发现，我现在相信答案是：

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

Answer 1

为了笑，我只是追踪了 gcc 中如何使用 argv[0] (main.c -> top_lev.c -> opts.c -> ; langhooks.c），并且 argv[0] 当前的用途只不过是在失败时为 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 trace 操作数。

我不太熟悉所有这些不同的标准，但它看起来像更新的 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 实际上是指向 a 的符号链接
编译器名称类似于 gcc-version。
类似地，c++ 和 g++ 是指向
编译器命名为 g++-version。

基于此，我假设 cc 和 gcc 的行为方式相同。

Answer 4

我今天也有同样的疑问，我尝试自己找到它：

which - 确定可执行位置

file - 确定文件类型

$ which cc
 /usr/bin/cc

$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.

配置脚本没有考虑 Linux 系统上的 cc 可能是 gcc 的可能性。 所以，要小心你的假设有多深。

Answer 6

cc 只是调用编译器的 UNIX 方式，它适用于所有 Unices。

Answer 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 和 buff1 的内存段之间放置空间来实现的。 增益2？

也许有更多经验的人可以为这里的黑暗带来光明。

Answer 8

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

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

Answer 9

“不。无论是否通过“gcc”调用，GCC 的行为都是相同的
或“抄送”。”

[引自原帖。]

根据我在 Ubuntu 14.04 中的经验，情况并非如此。

当我使用以下命令编译程序时：

gcc -finstrument-functions test.c

我的代码行为没有发生任何变化。但是当我使用

cc -finstrument-functions test.c

它进行编译时，它的行为确实有所不同（在这两种情况下，我都将适当的更改合并到描述的代码中此处 使 -finstrument-functions 工作）。

Answer 10

考虑到它来自 UNIX，我会说“cc”是通用名称，“gcc”是实际的编译器。 即“gcc”提供“cc”，因此寻找“cc”的程序将找到并使用“cc”，而完全不知道正在使用的实际编译器。

另外，UNIX 程序应该不知道用于调用它们的实际名称（想想 Windows 桌面快捷方式 - 检查快捷方式的名称是没有意义的），所以，不，“gcc”和“cc”会执行以下操作：如果“cc”是“gcc”的链接，则同样的情况。

当然，除非“cc”不是符号链接，而是调用 gcc 的 shell 脚本。

Answer 11

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