将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在失败时提供报告.如果没有出现任何改变行为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的可能性.所以,要小心你的假设.