Linking C++ and Make variables LINK.o, LINK.cc (.cpp, .C)

[Michael Ludwig]

In a directory without a Makefile, just relying on built-in rules:

  :: make foo.o
  g++    -c -o foo.o foo.cpp

  :: make foo
  cc   foo.o   -o foo

Compiling C++ with the C++ compiler succeeds, linking the resulting
object file with just the C compiler fails. This works:

  :: make foo CC=g++
  g++   foo.o   -o foo

Is there no built-in linker variable for linking object files
compiled from C++ source code in GNU Make because by convention,
like their C brethren, they're compiled to .o files and the rule
for linking .o files is already occupied by the C toolkit?

Okay, what made me ask this question, other the fact that I'm
learning C++?

Running "make -p" without a Makefile will show you Make's default
variables and rules. Like those for linking; among others:

LINK.o   = $(CC) $(LDFLAGS) $(TARGET_ARCH)
LINK.cc  = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
LINK.C   = $(LINK.cc)
LINK.cpp = $(LINK.cc)

Or for compiling:

COMPILE.cc  = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c
COMPILE.C   = $(COMPILE.cc)
COMPILE.cpp = $(COMPILE.cc)

Let's take this last one; what rules is it used for?

%: %.cpp
        $(LINK.cpp) $^ $(LOADLIBES) $(LDLIBS) -o $@

Okay, it's for compiling and linking executables from C++ *source*
files. Same story for LINK.cc, just there the file extension is
.cc rather than .cpp. So, to be precise, these rules are based on
file extensions, which makes the whole thing easy to memorize.

Now, let's say you compile your C++ first to .o files, and then
link it. Trying to link using LINK.o (as a newbie might do) won't
get you anywhere since it invokes the C compiler, which will
complain:

  undefined reference to `std::cout'

Reason:

  Note that programs using C++ object files must always be linked
  with g++, in order to supply the appropriate C++ libraries.
  Attempting to link a C++ object file with the C compiler gcc
  will cause "undefined reference" errors for C++ standard library
  functions […] Undefined references to internal run-time library
  functions, such as __gxx_personality_v0, are also a symptom of
  linking C++ object files with gcc instead of g++. Linking the
  same object file with g++ supplies all the necessary C++
  libraries and will produce a working executable […]

http://www.network-theory.co.uk/docs/gccintro/gccintro_54.html

Which brings me back to my question: Why is there no built-in rule
for linking object files compiled from C++ (rather than C) source
code? Just because they can't be told apart by their file extension?

I realize I should rather be asking why C++ is compiled to files
sharing the .o extension? Okay, they're object files, after all,
just with dependencies on the C++ compiler's libraries. So source
files have distinct extensions, but the resulting object files
don't, despite the fact that they do need (as with C++) additional
input to be linked, so they're not all equal.

This is probably akin to asking why there are seven continents on
this planet, and there's not the slightest practical relevance to
this question - but still I'm curious if there's any story behind
this state of affairs. :)

Michael