Reputation: 372
Shortly before I asked this question : g++ undefined reference to library symbols
It seems I misused predefined variables of make, namely LINK.cpp. The error was that I linked the library before the objects instead of afterwards.
Now this raised the question what those variables, particularly the LINK.cpp one, are good for because they expand like this :
LINK.cpp = $(LINK.cc)
LINK.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
^
I usually store my libs in LDFLAGS variable, which I thought was common, so LINK.cc will always link the libs before , because I can add my object files only after, and will cause errors like in the posted question.
Where do I have to put my objects then to use the LINK.cpp variable properly? Candidates are :
,which both seem not to be right. Have I gotten the use case of the variable wrong ?
To be clear : The question does not aim at the errors a linker can throw at you, but the usage of the variables in make.
Upvotes: 2
Views: 786
Reputation: 61575
I usually store my libs in LDFLAGS variable, which I thought was common
It is a fairly common mistake. The conventional meanings of the make variables that figure in C or C++ compilation are:-
CFLAGS
: Compilation options for CCXXFLAGS
: Compilation options for C++CPPFLAGS
: Preprocessor options for C or C++LDFLAGS
: Linkage options, excluding library (-l
) optionsLDLIBS
: Libraries or library (-l
) options for linkage.These are the meanings assumed in GNU Make's builtin rules.
The intended use of the variable:
LINK.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
is therefore as in:
prog: $(OBJS)
$(LINK.cc) $^ $(LDLIBS) -o $@
with the libraries following the object files.
(The variable TARGET_ARCH
appears in builtin rules evidently with the
intended meaning target-architecture options, but is nontheless undocumented).
Upvotes: 4