I work with C and C++ and thanks to this answer I was able to compile and run my project. Now I am writing a makefile to spare time. But things are getting complicated :
Project structure
project
makefile
client
bin
src
c
cc
java
server
...
# Directories
# CLIENT
CLIENT_BIN_DIR = /client/bin/
CLIENT_SRC_C_DIR = /client/src/c/
CLIENT_SRC_CC_DIR = /client/src/cc/
CLIENT_SRC_JAVA_DIR = /client/src/java/
# SECC
SERVER_BIN_DIR = /server/bin/
SERVER_SRC_C_DIR = /server/src/c/
SERVER_SRC_CC_DIR = /server/src/cc/
SERVER_SRC_JAVA_DIR = /server/src/java/
# Files
# CLIENT
CLIENT_BIN = ${CLIENT_BIN_DIR}client_app
CLIENT_SRC_C = ${wildcard ${CLIENT_SRC_C_DIR}*.c}
CLIENT_SRC_CC = ${wildcard ${CLIENT_SRC_CC_DIR}*.cc}
CLIENT_SRC_JAVA = ${wildcard ${CLIENT_SRC_JAVA_DIR}*.java}
# SERVER
SERVER_BIN = ${SERVER_BIN_DIR}server_app
SERVER_SRC_C = ${wildcard ${SERVER_SRC_C_DIR}*.c}
SERVER_SRC_CC = ${wildcard ${SERVER_SRC_CC_DIR}*.cc}
SERVER_SRC_JAVA = ${wildcard ${SERVER_SRC_JAVA_DIR}*.java}
# Flags
CFLAGS = -g -W -Wall
IFLAGS = -I${INC_DIR}
# Compilers
C = gcc
CC = g++
# Rules
all: ${CLIENT_BIN} ${SERVER_BIN}
${CLIENT_BIN}:
${SERVER_BIN}:
// NEED HELP HERE
Now that I have all the sources files, what should I write to the followings steps to every files :
gcc -c -o file.o file.c
g++ -c -o file.o file.cc -I/PATH_TO_C_HEADER
g++ -o APP_NAME C_O_FILES CC_O_FILES
make has built-in rules for compiling C and C++ files into object files, you can use those instead of writing your own by using the built-in flags they expect. Similarly make has a rule for building a binary from object files (as long as the binary matches one of the source files exactly).
Compiling C programs
n.o is made automatically from n.c with a recipe of the form ‘$(CC) $(CPPFLAGS) $(CFLAGS) -c’.
Compiling C++ programs
n.o is made automatically from n.cc, n.cpp, or n.C with a recipe of the form ‘$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c’. We encourage you to use the suffix ‘.cc’ for C++ source files instead of ‘.C’.
Linking a single object file
n is made automatically from n.o by running the linker (usually called ld) via the C compiler. The precise recipe used is ‘$(CC) $(LDFLAGS) n.o $(LOADLIBES) $(LDLIBS)’.
This rule does the right thing for a simple program with only one source file. It will also do the right thing if there are multiple object files (presumably coming from various other source files), one of which has a name matching that of the executable file. Thus,
x: y.o z.o
when x.c, y.c and z.c all exist will execute:
cc -c x.c -o x.o
cc -c y.c -o y.o
cc -c z.c -o z.o
cc x.o y.o z.o -o x
rm -f x.o
rm -f y.o
rm -f z.o
In more complicated cases, such as when there is no object file whose name derives from the executable file name, you must write an explicit recipe for linking.
Each kind of file automatically made into ‘.o’ object files will be automatically linked by using the compiler (‘$(CC)’, ‘$(FC)’ or ‘$(PC)’; the C compiler ‘$(CC)’ is used to assemble ‘.s’ files) without the ‘-c’ option. This could be done by using the ‘.o’ object files as intermediates, but it is faster to do the compiling and linking in one step, so that’s how it’s done.
So just set the right flags (as used in those rules) and add the right .o file prerequisites to your binary targets and you should be done.
If you must use make, this could help get you started (just for C files):
# CLIENT
CLIENT_BIN_DIR = client/bin/
CLIENT_SRC_C_DIR = client/src/c/
# CLIENT
CLIENT_BIN = $(CLIENT_BIN_DIR)client_app
CLIENT_SRC_C = $(wildcard $(CLIENT_SRC_C_DIR)*.c)
CLIENT_SRC_C_O = $(CLIENT_SRC_C:.c=.o)
CLIENT_SRC_C_D = $(CLIENT_SRC_C:.c=.d)
# Flags
CFLAGS = -g -W -Wall
IFLAGS = -I$(INC_DIR)
# Compilers
C = gcc
#Create header dependency files (included headers are dependencies too)
%.d: %.c
$(C) $(CFLAGS) -MM -MF $# -MT $*.o $<
#include will remake the dependency files if they need to be
-include $(CLIENT_SRC_C_D)
#O files will be created via the implicit rule
$(CLIENT_BIN): $(CLIENT_SRC_C_O)
$(C) $(CFLAGS) $(LDFLAGS) $^ -o $(#)
all: $(CLIENT_BIN)
https://www.gnu.org/software/make/manual/make.html is really helpful.
Otherwise, if you can, I recommend tup, which is easier, more flexible, faster, and more advanced than make.
# client binary depends on c and c++ .o's
$(CLIENT_BIN): $(CLIENT_SRC_C:.c=.o) $(CLIENT_SRC_CC:.cc=.o)
# server binary depends on c and c++ .o's
$(SERVER_BIN): $(SERVER_SRC_C:.c=.o) $(SERVER_SRC_CC:.cc=.o)
# example header dependency (file.cc depends on file.h and file1.h)
$(CLIENT_SRC_CC_DIR)file.o: $(CLIENT_SRC_CC_DIR)file.h $(CLIENT_SRC_CC_DIR)file1.h
GNU Make has implicit rules for compile C and C++ source files and generating the final binary, so there's no need to rewrite them.
Also, you might want to RTFM.
Related
I have started a SDL2-project where I have a source file containing the main function which depends on several of my own header and object files which are in other folders. My directory structure is as follows
/SDL2 // Top-Level directory of all my SDL2 projects
-> /projectX // My current project
-> main.cpp
-> /obj_sdl2_ana // Directory of all self-made object files
-> ...object files
-> ...source files of object files
-> /include_sdl2_ana // Directory of all self-made header files
-> ..header files
To compile and link main.cpp against my object and header files I have written the following Makefile
TARGET = main
FILETYPE = cpp
OBJDIR = ../obj_sdl2_ana/ # Directory with self-made object files
INCDIR = ../include_sdl2_ana/ # Directory with self-made header files
IFLAGS = -I$(INCDIR)
LFLAGS = -lSDL2 -lSDL2_image # insert all necessary libraries into it
VPATH = $(OBJDIR):$(INCDIR)
ADD_RESOURCES = common_ana
ADD_INC := $(ADD_RESOURCES:%=$(INCDIR)%.hpp) # specify header files which are prerequisites
ADD_OBJ := $(ADD_RESOURCES:%=$(OBJDIR)%.o) # specify additional object files which are prerequisites
$(TARGET): $(TARGET).o $(ADD_OBJ)
g++ $(TARGET).o $(ADD_OBJ) -g3 -o $(TARGET) $(LFLAGS)
$(TARGET).o: $(TARGET).$(FILETYPE) $(ADD_INC)
g++ -c $(TARGET).$(FILETYPE) $(IFLAGS) -g3 -o $(TARGET).o $(LFLAGS)
$(ADD_OBJ): $(OBJDIR)%.o: $(OBJDIR)%.cpp $(INCDIR)%.hpp
g++ -c $< $(IFLAGS) -g3 -o $# $(LFLAGS)
I have tested this with only one object file (common_ana.o) and the corresponding header file (common_ana.hpp) but the problem is that make is tossing a "Multiple target pattern" error at the rule
$(ADD_OBJ): $(OBJDIR)%.o: $(OBJDIR)%.cpp $(INCDIR)%.hpp
g++ -c $< $(IFLAGS) -g3 -o $# $(LFLAGS)
I have absolutely no clue, why this error appears. The Gnu make manual suggests that this error appears when there is a misuse of static pattern rules. But I have triple-checked my Makefile and couldn't find anything which would justify the error message of gnu make. While I'm aware of a workaround, I would be really glad if someone could give me a hint, what I have done wrong with respect to the above static pattern rule.
Make is including the extra space before your comments, try something the following
# Directory with self-made object files
OBJDIR = ../obj_sdl2_ana/
# Directory with self-made header files
INCDIR = ../include_sdl2_ana/
IFLAGS = -I$(INCDIR)
# insert all necessary libraries into it
LFLAGS = -lSDL2 -lSDL2_image
Same applies to the other lines, it's best to avoid inline comments.
I am working on a makefile for a C++ project that needs to support a few configurations, i.e. debug , release and maybe a few more customized ones in the future.
Currently, my naming convention for generated .o files is $(SOURCE_FULLPATH).$(CONFIGURATION).o. For instance, ABC.cpp generates ABC.cpp.debug.o in debug mode.
Now I would like to write the pattern rule for generating those object files in a configuration-independent way. What I did was: from each XX.o filename, I strip the .debug or .release suffix from XX, and use the remaining part of XX as the source filename.
%.o: $$(basename %)
$(CC) $(CC_FLAGS) $(INCLUDE_FOLDERS) -c -o $# $<
With this trick, I can build the executable correctly, except that I get one warning message from make:
make: Circular makefile.o <- makefile dependency dropped.
I am puzzled because I do not list makefile or makefile.o as a target or dependency anywhere in my makefile. I did a search on SO, but most questions about Circular dependency is on a specific user source file, rather than the makefile itself. Can anyone help me understand what causes the circular dependency, and how to get rid of this warning message?
A sample makefile that can reproduce this issue is listed below.
.SECONDEXPANSION:
PROJECT := helloworld
CC := clang++
BUILD_FOLDER := Build
OBJ_FILE_SUFFIX := .o
# Source
CPP_FILES :=\
Source/hello.cpp \
Source/mysqrt.cpp \
INCLUDE_FOLDERS := \
-IInclude
# MMD outputs the dependency files (".d" files). These files will be used by
# this makefile to allow for dependency checking on .h files.
CC_FLAGS += -MMD
EXISTING_OBJ_FILES = $(wildcard $(addsuffix *.o, $(basename $(CPP_FILES))))
##--------------------
## Targets definition
##--------------------
.PHONY:default
default: all
.PHONY:all
all: debug release
.PHONY:debug release
# Add a 'debug'/'release' suffix to the name of the object file
# e.g. hello.cpp -> hello.cpp.debug.o
debug release: OBJ_FILES=$(addsuffix .$#$(OBJ_FILE_SUFFIX), $(CPP_FILES))
debug release: $${OBJ_FILES} # Use Secondary Expansion to get the obj names
$(CC) $^ -o $(BUILD_FOLDER)/$(PROJECT)_$#
# Strip configuration name from the end of the object file name
%.o: $$(basename %)
$(CC) $(CC_FLAGS) $(INCLUDE_FOLDERS) -c -o $# $<
## clean: remove executable, all object files, and all dependency files
.PHONY:clean
clean:
-rm -f $(BUILD_FOLDER)/$(PROJECT) $(EXISTING_OBJ_FILES) $(EXISTING_OBJ_FILES:.o=.d)
# Include the dependent files so that in later builds, modified .h files
# will cause all .cpp dependent on them to rebuild
-include $(OBJ_FILES:.o=.d)
The folder structure is
makefile
Source
- hello.cpp
- mysqrt.cpp
Include
- mysqrt.h
The full output of make debug is
make: Circular makefile.o <- makefile dependency dropped.
clang++ -MMD -IInclude -c -o Source/hello.cpp.debug.o Source/hello.cpp
clang++ -MMD -IInclude -c -o Source/mysqrt.cpp.debug.o Source/mysqrt.cpp
clang++ Source/hello.cpp.debug.o Source/mysqrt.cpp.debug.o -o Build/helloworld_debug
Everything is good except for the first line.
I would also really appreciate it if anyone can point to me if there is any bad practice in my makefile (I am still a newbie in makefile). Thank you in advance!
GNU Make always attempts to update the makefile(s) it has read before
making anything else. If it finds rules and prerequisites that tell it
to update makefile(s), then it does so and then starts again from scratch -
including attempting to update the makefile(s). See 3.5 How Makefiles Are Remade.
In your recipe:
%.o: $$(basename %)
$(CC) $(CC_FLAGS) $(INCLUDE_FOLDERS) -c -o $# $<
you have provided make with a rule for making makefile.o from makefile.
It is also the inverse of the rule in the builtin recipe
%: %.o
$(LINK.o) $^ $(LOADLIBES) $(LDLIBS) -o $#
which makes an executable from a single object file. So your recipe has introduced the circularity:
makefile.o <- makefile <- makefile.o
when make is considering makefile itself as a target.
You could suppress the circularity by expressly deleting the builtin inverse rule,
by writing the empty rule:
%: %.o
in the makefile. Then you could observe the following confusion on the part of the
compiler:
$ make makefile.o
clang++ -c -o makefile.o makefile
clang: warning: makefile: 'linker' input unused
And the same would occur if you attempted to make any target that depended
on makefile.o.
It is probably safe to assume that you will have no targets that depend on
makefile.o. Nevertheless a rule that would attempt to
compile foo.o from any existing file foo is clearly more sweeping that you
want or need. For the particular pattern of dependency that you wish to capture:
foo.cpp.{debug|release}.o: foo.cpp
You'd be better off with:
%.o: $$(basename $$(basename %)).cpp
$(CC) $(CC_FLAGS) $(INCLUDE_FOLDERS) -c -o $# $<
Note, BTW, that in GNU Make conventions - the conventions that are
assumed by GNU Make's builtin rules - CC denotes your C compiler while
CXX denotes your C++ compiler. Likewise flags for the C compiler are
denoted CFLAGS and flags for the C++ compiler are denoted CXXFLAGS.
Flags for the preprocessor are denoted CPPFLAGS, and -Ipath options
- which are preprocessor options - are conventionally be passed through CPPFLAGS.
After compiling some code using a Makefile I get this when I try to run it:
$ ./libbookgui.a
./libbookgui.a: line 1: syntax error near unexpected token `newline'
./libbookgui.a: line 1: `!<arch>'
The Makefile has the following contents.
INCLUDES = -I"$(FLTK)"
LIBS = -lstdc++
CXXFLAGS = $(INCLUDES) -Wall -time -O3 -DNDEBUG -Wno-deprecated
LIBFLAGS =
AR = ar
.SUFFIXES: .cpp .o
# Create a list of source files.
SOURCES = $(shell ls *.cpp)
# Create a list of object files from the source file lists.
OBJECTS = ${SOURCES:.cpp=.o}
# Create a list of targets.
TARGETS = libbookgui.a
# Build all targets by default
all: $(TARGETS)
%.a: $(OBJECTS)
$(AR) rcs $# $(OBJECTS)
# A rule to build .o file out of a .cpp file
%.o: %.cpp
$(CXX) $(CXXFLAGS) -o $# -c $<
# A rule to clean all the intermediates and targets
clean:
rm -rf $(TARGETS) $(OBJECTS) *.out *.stackdump
I see that it has the line TARGETS = libbookgui.a and the compiler doesn't return any errors it just creates the .a file.
Any ideas?
libbookgui.a is a static library (that aggregates several object files in it).
You are supposed to run executables, not libraries. Link this library into some executable and run that.
I suggest you read this article.
You need to update your post to show the changes you made to the makefile to get the link line added. Without that we can't really help you with that part of the problem.
Based on the errors my suspicion is that you're not using the right tool for linking: you're either using "gcc" (C compiler front-end) or trying to invoke the linker directly. When you link your application you should use the C++ compiler (in your case, $(CXX)). You also don't need to specify -lstdc++, since the C++ front-end will automatically add that to the link line.
I wrote a Makefile(code below) for my program which contains hello.h, hello.cpp and main.cpp (this is a trivial testbench for hello.cpp).
However, after I type make in the terminal, it tells me
make: `hello.o' is up to date.
Can someone give any hints? Thank you!
#MACRO
CAT_HOME = $(MGC_HOME)
TARGET = my_tb
#OBJECT1 = hello.o
OBJECTS = hello.o main.o
#OBJECT2 = main.o
DEPENDS = hello.cpp main.cpp hello.h
INCLUDES = -I"$(CAT_HOME)/shared/include"
DEFINES =
CXX = /usr/bin/g++
CXXFLAGS = -g -O3 $(DEFINES) $(INCLUDES)
$(TARGETS) : $(OBJECTS)
$(CXX) $(CXXFLAGS) -o $(TARGET) $(OBJECTS)
$(OBJECTS) : $(DEPENDS)
#phony target to remove all objects and executables
.PHONY: clean
clean:
rm -f *.o
You define a TARGET variable but later try to use $(TARGETS). Theres an S in difference.
Also, it is inefficient to let every .o file depend on every .cpp file. You might as well just write a linear script that recompiles everything unconditionally. Since you're depending on make's built-in rule for creating a .o from the corresponding .cpp, you don't need to declare that dependency explicitly. So you can remove all of the .cpp files from DEPENDS without losing any relevant dependencies.
I work in a computational biophysics lab. I am not a programmer, although I do get paid to act like one. Here's my problem: the main product of the lab is a ginormous (50+ source files) C program. I need to get our lab's program to work with another lab's toolkit, which just so happens to be in the form of a series of C++ libraries (.a files). I can get the main library for our program to compile using the following makefile:
CC = gcc
#CC = icc
CFLAGS = -g -Wall
#CFLAGS = -xT -openmp -I/opt/local/include -I/usr/local/include -I/opt/GDBM/include
#CFLAGS = -O3 -g -Wall -I/opt/GDBM/include -fopenmp
LIB = mcce.a
AR = ar
ARFLAGS = rvs
SRC = all.c ddvv.c geom_3v_onto_3v.c ins_res.c strip.c\
app.c del_conf.c geom_apply.c line_2v.c vdotv.c\
avv.c del_prot.c geom_inverse.c load_all_param.c vector_normalize.c\
avvvv.c del_res.c geom_move.c load_param.c vector_vminusv.c\
cpy_conf.c det3.c geom_reset.c mxm4.c vector_vplusv.c\
cpy_prot.c det4.c geom_roll.c new_prot.c vector_vxv.c\
cpy_res.c dll.c get_files.c param_get.c param_exist.c\
db_close.c dvv.c iatom.c param_sav.c\
db_open.c free_strings.c ins_conf.c plane_3v.c pdbline2atom.c\
premcce.c init.c load_pdb.c write_pdb.c rotamers.c assign_rad.c get_connect12.c\
surfw.c vdw.c vdw_conf.c shuffle_n.c cmp_conf.c sort_conf.c sort_res.c id_conf.c\
energies.c assign_crg.c coulomb.c coulomb_conf.c\
get_vdw0.c get_vdw1.c relax_water.c relax_h.c monte.c monte2.c ran2.c\
relaxation.c collect_connect.c torsion.c vdw_fast.c hbond_extra.c swap.c quick_e.c\
check_tpl.c zip.c del_dir.c make_matrices.c\
mem_position.c probe.c add_membrane.c load_pdb_no_param.c ga_engine.c rotamers_ga.c compute_patches.c
OBJ = $(SRC:.c=.o)
HEADER = mcce.h
$(LIB): $(OBJ)
$(AR) $(ARFLAGS) $(LIB) $(OBJ)
$(OBJ): $(HEADER)
.c.o:
$(CC) $(CFLAGS) -c $*.c
clean:
rm -f *.o mcce.a
The executable itself then compiles with this makefile:
CC = gcc -g -O3
#CC = icc -xT -static-intel -L/opt/local/lib -L/usr/local/lib
mcce: mcce.c lib/mcce.h lib/mcce.a
# $(CC) -o mcce mcce.c mcce.a /opt/GDBM/lib/libgdbm.a -lm -lz -openmp; cp mcce bin
$(CC) -o mcce mcce.c lib/mcce.a -lgdbm -lm -lz -fopenmp; cp mcce bin
I can get a standalone version of the other lab's code to compile using this other makefile:
OEDIR = ../..
INCDIR = $(OEDIR)/include
LIBDIR = $(OEDIR)/lib
INCS = -I$(INCDIR)
LIBS = -L$(LIBDIR) \
-loezap \
-loegrid \
-loefizzchem \
-loechem \
-loesystem \
-loeplatform \
-lz \
-lpthread -lm
CXX = /usr/bin/c++
RM = rm -f
CXXFLAGS = -m64 -W -Wall -O3 -fomit-frame-pointer -ffast-math
LFLAGS = -m64 -s
TEXT2HEX = ../text2hex
PROGRAMS = other_labs_code
.SUFFIXES: .cpp
.SUFFIXES: .o
.cpp.o:
$(CXX) $(CXXFLAGS) $(INCS) -c $<
.SUFFIXES: .txt
.SUFFIXES: .itf
.txt.itf:
$(TEXT2HEX) $< InterfaceData > $#
all: $(PROGRAMS)
clean:
$(RM) $(PROGRAMS)
$(RM) ii_files core a.out *.itf
$(RM) *.o
other_labs_code.o: other_labs_code.cpp other_labs_code.itf
other_labs_code: other_labs_code.o
$(CXX) other_labs_code.o $(LFLAGS) -o $# $(LIBS)
I know that I have to change the paths of the various libs and stuff, but other than that, how do I combine all of these makefiles into one working product? Also, since some of the source files that go into compiling my program's main library (mcce.a) are going to need to be able to call functions from the C++ source file, it's the library's makefile that I need to modify, right?
I know extremely little about makefiles, so even if someone can just point me in the direction of a tutorial that covers this kind of problem (writing a makefile for a many source file C and C++ program), that may be sufficient.
For bonus points, the C++ FAQ says that:
You must use your C++ compiler when compiling main() (e.g., for static initialization)
Your C++ compiler should direct the linking process (e.g., so it can get its special libraries)
I don't exactly know what those things are supposed to mean, but assuming that I did, are there any other important points like that I should be aware about when combining C and C++?
Preparing the code
C programs cannot just use C++ symbols. Unless the authors of the C++ code arranged for that. This is because some features that C++ offers, such as function overloading (having several functions of the same name but with different formal arguments) demand that the function name be mangled in some way. Else the linker would see the same symbol defined several times. C compilers don't understand this name mangling and therefore cannot use C++ symbols. There are, generally, two possible solutions.
Declare and define all C++ symbols that the C code wants to use within extern "C" { ... } blocks and let your C++ tools handle the linking. The C code does not need to be changed in this case.
Compile the C code with the (exact same) C++ compiler as the C++ code. Fix the C++ compiler's complaints of the C code as they arise. Depending on project size and coding style, this may or may not be a lot of work.
Preparing a master Makefile
I personally try to avoid becoming intimate with other people's Makefiles, especially if they are subject to change or complex. So, assuming generating a Makefile that orchestrates the bits you already have (as opposed to writing one Makefile incorporating everything) is okay, I'd start out with something similar to this:
I'm assuming that
One of the above-mentioned options has been implemented
The code for mcce.a lies in subdirectory mcce/lib/
other_labs_code.cpp lies in other_labs_code/
The main function you want to use lies in ./mystuff.c
the following top-level Makefile may get you started
CXX = c++
CXXFLAGS = -m64 # From other_labs_code/Makefile
LDFLAGS = -m64 -L<path to OEDIR> # From other_labs_code/Makefile
LIBS = -lgdbm -lm -lz # From mcce/lib/Makefile
LIBS += -loezap \ # From other_labs_code/Makefile
-loegrid \
-loefizzchem \
-loechem \
-loesystem \
-loeplatform \
-lpthread
mystuff: mystuff.c mcce/lib/mcce.a other_labs_code/other_labs_code.o
$(CXX) $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) -o $# $^ $(LIBS)
mcce/lib/mcce.a:
cd mcce/lib/ && $(MAKE) CC="$(CXX) -m64" mcce.a
other_labs_code/other_labs_code.o:
cd other_labs_code/ && $(MAKE) other_labs_code.o
Makefile: mcce/lib/Makefile other_labs_code/Makefile
echo "Warning: `pwd`/$# is out of date" >&2
This Makefile will employ the existing sub-project Makefiles to do the compilations. If the sub-project Makefiles have a newer timestamp than this Makefile, potentially rendering it obsolete, then this will be warned about. The linking basically works by combining the required libraries of both sub-projects. I've removed duplicates. The compiler switches are basially those of the original authors since compiling is delegated to the sub-projects. The code both sub-projects generate must be for the same platform. If your compiler is gcc/g++ then either -m64 is the default and therefore redundant in the second project or should be added to the first project. I have illustrated injecting it into the first project without changing their Makefile (using GNU make). NB: This example also causes the first project to be compiled with the C++ compiler.
An extern "C" {...} block located in a C or C++ header file that C code wants to include should look like this
/* inclusion guard etc */
#if defined(__cplusplus)
extern "C" {
#endif
/* C declarations */
#if defined(__cplusplus)
}
#endif
/* inclusion guard etc */
Minor points
In the first posted Makefile, I suggest changing the bottom part to
.c.o:
$(CC) $(CFLAGS) -c -o $# $<
clean:
rm -f $(OBJ) mcce.a
.PHONY: clean
which is a tiny bit cleaner.
The second Makefile is broken. The bottom rule links the binary and then copies it to a directory named bin, if it exists, else a copy of the file is created and named `bin'. If the linking fails, that fact is not propagated to the caller, i.e. the error is ignored. The bottom rule should read
mcce: mcce.c lib/mcce.h lib/mcce.a
$(CC) -o $# mcce.c lib/mcce.a -lgdbm -lm -lz -fopenmp
cp mcce bin/
i.e. the link command should be on its own line and that `bin' is supposed to be a directory should be made explicit.
http://www.gnu.org/software/make/manual/make.html#Introduction