Invoking GCC as "cc" versus "gcc"

Question

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

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

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

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

Solution 3

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.

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

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

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

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.

View more solutions

Comments

[vpalmu]

gzip checks its name. If its name is gunzip it assumes -d.

[mateusza]

"Also, UNIX programs should be ignorant of the actual name used to call them" It's absolutely not true. Have you ever heard of multi-call binaries? I.e. Busybox? busybox.net

[Nubzor]

woah and a downvote without explanation - very helpful ... maybe they didn't like something?

[Dan Moulding]

The only problem that I have with that is that "cc --version" gives slightly different output from "gcc --version" (it says "cc" instead of "gcc"). So something in there must be looking at argv[0].

[Dan Moulding]

Interesting link. Someone should probably tell the GNU Make people about this, because it will still invoke "cc" as the default if you don't override ${CC}. Apparently they should be using one of the other utilities as a default. It would seem that c89 should be the preferred utility according to the standard.

[Dan Moulding]

OTOH, since that was written in 1997, maybe these days the preferred utility ought to be c99.

[Dan Moulding]

Your answer motivated me to look into the source code myself. I found that argv[0] does get assigned to "programname" which ends up getting passed around a bit to other functions (and gets stored in the environment). Although I didn't do an exhaustive search, from what I can see, it is only ever used for display purposes (e.g. in the "--version" output, "usage" output, error messages, etc).

[bortzmeyer]

This does not address the question.

[AntonyFalegk]

Actually it does, cc means "C compiler" on Unix, nothing more.

[Johannes Schaub - litb]

yes, SUSv3 doesn't include c89 anymore. only the old one i linked to recommended it (SUSv2)

[Johannes Schaub - litb]

and, after all, "sh" is usually a symlink to "bash", which makes it behave as a POSIX shell. sh<->bash is actually very similar to cc<->gcc .

[Johannes Schaub - litb]

The questioner asked about the difference of cc and gcc too. This serves as an answer too and addresses the question, imo

[Nubzor]

Maybe they don't know that Mac OS X is fully posix compliant Unix system

[Alan Plum]

Well, gzip<->gunzip is a case of the same utility providing two different utilities. In the case of gcc<->cc it's providing one thing. I did make a generalisation about unix tools being argv[0] agnostic, but for the most part they are, simply because otherwise they'd break if renamed. If one binary provides more than one utility, then, yes, there's a difference between calling it directly and calling the symlink it creates to provide the tool in question, but gcc<->cc is not that: unless the semantics (i.e. expected behaviour) change, they're synonyms for historical reasons.

[EFraim]

No, perhaps they consider confusing the following logical chain: "symlinked to the same executable -> same behavior". For instance all your basic command line utils can be symlinked to busybox on minimal system, yet function as entirely separate utils

[Brooks Moses]

Note the comment that Javier gave to stefanB's answer, though -- Unix provides the "name of the program" to a program as the 0th command-line argument, and many programs in Unix are set up with symbolic links from many different names and change their behavior depending on which name was used to call them. (For instance, gunzip is a link to gzip, but if you call gzip it compresses things and if you call gunzip it uncompresses them.) Thus, it's entirely plausible that GCC might act differently if you run it via a symlink named 'cc'.

[Dan Moulding]

This goes without saying. The compiler isn't behaving any differently. This is a shortcoming of the configure script. The script knows that gcc can generate shared libraries and it knows that gcc needs the -fPIC option when compiling shared libraries on Linux. If the compiler is not gcc, then configure attempts to test whether the compiler can generate shared libraries. But it cannot divine what compiler flags are needed for a compiler that it does not know, so you the user must supply them. You need to supply the necessary flags on the command line (e.g. via CFLAGS=-fPIC).

[ednos]

This was intended as an auxiliary caution rather than an answer. Invoking gcc as cc in the above case would not cause it to operate differently, but the invoking software operated in a nonintuitive manner that caused the appearance of different behavior.

[Johannes Schaub - litb]

I just came to notice that this is true only if cc and gcc are the same executable. May it happen that the system has different binaries? Imaginr that cc may link to a clang binary and gcc to gcc. Honest question, I have no idea.

[Kyslik]

I tried this (on gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)), with stack protector off and on and both end with either segmentation fault or stack smashing detected, in the end cc is link to /etc/alternatives/cc and that is link to /usr/bin/gcc. As @abcoep says cc and gcc differs only with tab completion (as far as I could investigate).