Page MenuHomeFreeBSD

Remove the non-standard CC alias for c++

Authored by dim on Feb 21 2015, 9:15 PM.



Since r34282 (almost 17 years ago) we have been carrying the alias 'CC'
for 'c++, to invoke the C++ compiler. The original reason in O'Brien's
commit message is "for compatibility with SGI".

This alias is not based on any standard, is not compatible with case
insensitive filesystems, and does not seem to be used by any other
operating system. So let's finally get rid of it.

Test Plan

Do an exp-run, probably. I expect zero breakage.

Diff Detail

rS FreeBSD src repository
Lint ErrorsExcuse: Phabricator chokes on + characters in filenames? Why?
Errorgnu/usr.bin/cc/c++/Makefile:NAME1Bad Filename
No Unit Test Coverage

Event Timeline

dim updated this revision to Diff 3899.Feb 21 2015, 9:15 PM
dim updated this revision to Diff 3900.
dim retitled this revision from to Remove the non-standard CC alias for c++.
dim updated this object.
dim edited the test plan for this revision. (Show Details)
dim added reviewers: emaste, theraven.
dim added a subscriber: Unknown Object (MLST).

Added one more instance of CC.1.

theraven accepted this revision.Feb 21 2015, 9:27 PM
theraven edited edge metadata.

Thank you!

This revision is now accepted and ready to land.Feb 21 2015, 9:27 PM
emaste accepted this revision.May 26 2015, 8:03 PM
emaste edited edge metadata.
dim updated this revision to Diff 5715.May 26 2015, 8:44 PM
dim edited edge metadata.

Updated for changes in

This revision now requires review to proceed.May 26 2015, 8:44 PM
imp added a comment.May 26 2015, 9:28 PM

CC has been an alias for the default C++ compiler the entire life FreeBSD has had a C++ compiler.

Sure, it isn't based on any "standards" but it is a very de-facto standard that many ports rely on.
FreeBSD isn't the only system to do this. Sun did this for years, as did SGI, and many other folks
that had a C++ compiler based on cfront. IIRC CC was a shell script front end for cfront in at least
the cfront 2.0 and 3.0 time frame. Many ISV's compilersr picked up on this de-facto standard and
have been providing the link for a long time.

imp requested changes to this revision.May 26 2015, 9:30 PM
imp added a reviewer: imp.

So "it is icky" likely isn't a good enough reason.

Do a ports run w/o it causing any problems and prove me wrong...

This revision now requires changes to proceed.May 26 2015, 9:30 PM
In D1932#49686, @imp wrote:

it is a very de-facto standard that many ports rely on.

Many ports will choose CC if it exists, but I'm not sure they rely on it. Autoconf and cmake builds will try a list and if they pick c++ next they'll be fine.
exp-run requested in

kib added a subscriber: kib.May 27 2015, 8:37 AM

On what standard the name of the C++ compiler is based, at all ?
What are supposed benefits of the change ?

I believe I already noted elsewhere to dim that the CC is long-time established name. Not all software built on FreeBSD live in the ports framework. Loosing zero-cost convenience feature is not very smart.

It is problematic for the compiler to differentiate between being invoked as CC and as cc (clang and gcc both have to work on case-insensitive filesystems). The convention to have CC as an alias for c++ comes from some SysV platforms (though not from Linux, which does not install the CC alias). On OS X, cc and CC are the same file, as the filesystem is case preserving but not case sensitive.

As a result of this, we have been carrying around patches to clang to make it detect that it is being invoked as CC for a while, to avoid breaking every single cmake-built C++ program (a few hundred ports) that defaults to CC as the C++ compiler (for Solaris/IRIX compatibility), but will happily fall back to using c++ instead.

Aside from the cost of maintaining this patch, this also adds a place where the obj dir / install sysroot must be on a case-sensitive filesystem, which harms attempts to make FreeBSD cross-buildable from OS X / Windows (we are careful to avoid this requirement for the src tree and have an svn hook to prevent it).

The CC alias does not work on Linux or OS X, so the likelihood of this breaking third-party code is minimal and the pain that it has already caused is nontrivial.

bdrewery accepted this revision.May 27 2015, 1:50 PM
bdrewery added a reviewer: bdrewery.
bdrewery added a subscriber: bdrewery.


'CC' is easily confused with '${CC}' and is difficult to even discuss. So much of the development ecosystem tells people to use 'gcc' or 'g++' anyhow, removing 'CC' is unlikely to cause any issues today.

dim added a comment.EditedMay 29 2015, 9:55 PM

An exp-run was requested in bug 200475. Out of ~25000 ports, only 5 failed, and those have been trivially fixed.
The ports tree no longer requires CC to exist.

dim added a comment.Jun 1 2015, 5:49 PM

@imp, so are your concerns now addressed? I didn't expect many ports to fail, and there were just a handful, three of which were actual errors (they indended to run ${CC}, but somebody typo'd CC instead).

What are we doing with this?

dim added a comment.Aug 15 2015, 8:55 AM

The exp-run proved that the alias is not really necessary. I think very few people, if any at all, consciously use 'CC' for compiling C++ programs in this day and age. :)

dim abandoned this revision.Feb 11 2016, 8:55 PM

We chose to go for a shell script wrapper instead.