[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Linking C++ and Make variables LINK.o, LINK.cc (.cpp, .C)
From: |
Michael Ludwig |
Subject: |
Linking C++ and Make variables LINK.o, LINK.cc (.cpp, .C) |
Date: |
Sun, 29 Jan 2012 23:29:34 +0100 |
User-agent: |
Mutt/1.5.20 (2009-12-10) |
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
- Linking C++ and Make variables LINK.o, LINK.cc (.cpp, .C),
Michael Ludwig <=