[ACCEPTED]-Invoking GCC as "cc" versus "gcc-gnu

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

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

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

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

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

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

On my mac from man gcc:

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

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

I had the same doubt today and I tried to 4 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 3 to gcc.

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

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

When building zlib 4 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 3 configure script does not consider the possibility 2 that cc on a Linux system could be gcc. So, be 1 careful how far you take your assumptions.

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

this thread might be old but I want to add 11 something to it (maybe someone will find 10 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 9 "gcc", and you pass it "AAAAAAAAAAAAAAAAAAAAAAAAA" as 8 argument, it will not overflow into buffer2, while 7 it DOES if you compiled with "cc", which 6 for me is a hint that if you used "gcc", the 5 memory management works different, maybe 4 by putting space between the memory segments 3 of the fields buff1 & buff2 ?

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

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

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

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

[Quoted 8 from original post.]

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

When 6 I compile my program using:

gcc -finstrument-functions test.c

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

cc -finstrument-functions test.c

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

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

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

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

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