Invoking GCC as "cc" versus "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?

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"?

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:

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

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.

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:

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

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

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

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 :)

On my mac from man 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.

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

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.

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

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.

When building zlib 1.2.5 on RHEL 5.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.

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

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 ?

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

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:

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

> "No. GCC behaves the same regardless of whether it is called via 'gcc' > or 'cc'." > >[Quoted from original post.]

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

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

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.

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

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

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