以“cc”和“GCC”调用GCC

I am aware that on most GNU/Linux systems, GCC can be invoked by the name "cc" from the command line (as opposed to "gcc"). Is there any difference in GCC's behavior when it is invoked one way versus the other?

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

For example, I know that invoking GCC through the name "g++" instead of "gcc" causes GCC to behave differently (it treats .c files as C++ source and links-in the C++ standard library). Is there any similar difference in behavior between "gcc" versus "cc"?

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

EDIT: None of the answers received so far gave a definitive "yes" or "no" as to whether GCC will behave differently if invoked one way versus the other. However, the idea given to dive into the source to check its behavior lead me down that path. Based upon what I found there, I now believe that the answer is:

编辑:到目前为止收到的回答中没有一个给出明确的“是”或“否”，以确定如果以一种方式与另一种方式调用GCC是否会有不同的行为。然而，让我潜入源头来检查它的行为的想法使我走上了那条道路。基于我在那里的发现，我现在相信答案是:

No. GCC behaves the same regardless of whether it is called via "gcc" or "cc".

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

11 个解决方案

#1

For grins, I just traced down how argv[0] is used from within gcc (main.c -> top_lev.c -> opts.c -> langhooks.c) and it appears that argv[0] is currently used for nothing more than giving malloc something to report when it fails. There doesn't appear to be any behavior change if argv[0] is anything other than gcc.

对于微笑，我只是跟踪了argv[0]是如何从gcc (main)中使用的。c - > top_lev。c - >选择。c -> langhoks .c)而argv[0]目前的用途似乎只是在失败时向malloc报告一些东西。如果argv[0]是除gcc之外的任何东西，则没有任何行为改变。

#2

It looks to me that cc (link to some old SUS specification) is intended to be the vendor-neutral interface to the system's compiler. It's marked as legacy:

在我看来，cc(链接到一些旧的SUS规范)应该是系统编译器的供应商中立接口。标记为遗产:

The c89 utility provides an interface to the ISO C standard, but the cc utility accepts an unspecified dialect of the C language: it may be Standard C, common-usage C or some other variant. Portable C programs should be written to conform to the ISO C standard and compiled with c89.

c89实用程序提供了ISO C标准的接口，但是cc实用程序接受C语言的一种未指定的方言:它可能是标准C、通用C或其他变体。可移植的C程序应该按照ISO C标准编写，并与c89一起编译。

POSIX has a utility called c99 which I believe is the successor of c89. It says

POSIX有一个叫做c99的实用程序，我相信它是c89的继承者。它说

The c99 utility is based on the c89 utility originally introduced in the ISO POSIX-2:1993 standard. Some of the changes from c89 include the modification to the contents of the Standard Libraries section to account for new headers and options; for example, added to the -l rt operand, and the -l trace operand added for the Tracing functions.

c99实用程序是基于c89实用程序，它最初是在ISO POSIX-2:1993标准中引入的。c89的一些更改包括对标准库部分内容的修改，以考虑新的标题和选项;例如，添加到-l rt操作数和为跟踪函数添加的-l跟踪操作数。

I'm not really familiar to all those different standards, but it looks like the more recent SUSv3 (POSIX:2004) and the yet more recent POSIX:2008 (doesn't seem to have a SUS number yet) do not specify a utility called cc anymore, but only the utility called c99. Incidentally, my Linux system (Arch_Linux) contains a manpage of c99 but not c89, but only contains a utility called cc, but neither c89 nor c99. Much confusion in there :)

我对所有这些不同的标准并不熟悉，但它看起来像最近的SUSv3 (POSIX:2004)和最近的POSIX:2008(似乎没有一个SUS编号)没有指定一个名为cc的实用程序，但只指定了名为c99的实用程序。顺便说一句，我的Linux系统(Arch_Linux)包含c99的manpage，但不包含c89，但只包含一个名为cc的实用程序，但既不包含c89也不包含c99。很混乱:)

#3

On my mac from man gcc:

在我的mac上，来自人类gcc:

In Apple's version of GCC, both cc and gcc are actually symbolic links to a compiler named like gcc-version. Similarly, c++ and g++ are links to a compiler named like g++-version.

在苹果版本的GCC中，cc和GCC实际上都是指向一个名为GCC -version的编译器的符号链接。类似地，c++和g++是一个名为g++-version的编译器的链接。

Based on that I would assume that cc and gcc behave the same way.

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

#4

I had the same doubt today and I tried to find it on my own:

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

$ 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

So, basically cc points to gcc.

基本上cc指向gcc。

You could also check using cc -v and gcc -v. If they print out the same thing, that means they are exactly the same.

您还可以使用cc -v和gcc -v检查。如果它们打印出来的是一样的东西，那就意味着它们是完全一样的。

#5

Even if gcc operates the same independent of argv[0]'s value, not all software will operate the same regardless of which you specify as the compiler.

即使gcc独立于argv[0]的值运行相同的操作，也不是所有的软件都将运行相同的操作，不管您指定哪个为编译器。

When building zlib 1.2.5 on RHEL 5.5 (gcc 4.1.2):

在RHEL 5.5上构建zlib 1.2.5时(gcc 4.1.2):

$ md5sum $(which cc)
69a67d3029b8ad50d41abab8d778e799  /usr/bin/cc
$ md5sum $(which gcc)
69a67d3029b8ad50d41abab8d778e799  /usr/bin/gcc

But:

但是:

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

And:

和:

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

The configure script does not consider the possibility that cc on a Linux system could be gcc. So, be careful how far you take your assumptions.

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

#6

cc is just the UNIX way of calling the compiler, it will work on all Unices.

cc只是调用编译器的UNIX方式，它可以在所有Unices上工作。

#7

this thread might be old but I want to add something to it (maybe someone will find it in the future).

这个线程可能是旧的，但是我想给它添加一些东西(也许将来有人会找到它)。

If you compiled this program

如果你编译了这个程序

#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;
}

with "gcc", and you pass it "AAAAAAAAAAAAAAAAAAAAAAAAA" as argument, it will not overflow into buffer2, while it DOES if you compiled with "cc", which for me is a hint that if you used "gcc", the memory management works different, maybe by putting space between the memory segments of the fields buff1 & buff2 ?

“海合会”,你把它“AAAAAAAAAAAAAAAAAAAAAAAAA”作为参数,它不会溢出到buffer2,虽然它如果你编译“cc”,我认为这是一个提示,如果你使用gcc,内存管理工作不同,也许通过将字段的内存段之间的空间buff1 & buff2吗?

Maybe someone with more experiance can put light into the darkness here.

也许有更有经验的人可以把光放进黑暗里。

#8

Nothing in the GCC documentation indicates that GCC would behave any differently if its executable name is not gcc but cc. The GNU Fortran compiler even mentions that:

GCC文档中没有任何内容表明，如果GCC的可执行名称不是GCC而是cc，那么GCC的行为会有任何不同。

A version of the gcc command (which also might be installed as the system's cc command)

gcc命令的一个版本(也可以作为系统的cc命令安装)

#9

"No. GCC behaves the same regardless of whether it is called via 'gcc' or 'cc'."

“没有。不管它是通过“GCC”还是“cc”调用，GCC的行为都是相同的。

[Quoted from original post.]

(引用原文。)

Based on my experienced in Ubuntu 14.04, this hasn't been the case.

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

When I compile my program using:

当我使用:

gcc -finstrument-functions test.c

I don't get any change in the behavior of my code. But when I compile using

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

cc -finstrument-functions test.c

It does behave differently. (In both cases, I incorporated the appropriate changes into my code described here to make -finstrument-functions work).

它的行为不同。(在这两种情况下，我都将适当的更改合并到这里描述的代码中，以使-finstrument函数工作)。

#10

Considering this is coming from UNIX, I'd say that "cc" is the generic name and "gcc" is the actual compiler. i.e. "gcc" provides "cc" so a program looking for "cc" would find and use "cc", blissfully ignorant of the actual compiler being used.

考虑到这是来自UNIX，我认为“cc”是通用名称，“gcc”是实际的编译器。即。“gcc”提供了“cc”，因此寻找“cc”的程序可以找到并使用“cc”，并且非常幸运地不知道实际使用的编译器。

Also, UNIX programs should be ignorant of the actual name used to call them (think Windows Desktop shortcuts -- it doesn't make sense to check what the shortcut was called), so, no, "gcc" and "cc" do the same thing if "cc" is a link to "gcc".

另外，UNIX程序应该不知道调用它们的实际名称(想想Windows桌面快捷方式——检查快捷方式被调用是什么没有意义)，所以，如果“cc”是“gcc”的链接，那么“gcc”和“cc”也应该这样做。

Unless, of course, "cc" is not a symlink but a shellscript calling gcc.

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

#11

For my OS (Ubuntu 14.04) cc doesn't allow tab completion, whereas gcc does.

对于我的操作系统(Ubuntu 14.04)， cc不允许tab补全，而gcc允许。