I am trying to compile a simulation program called COSI:
http://www.broadinstitute.org/~sfs/cosi/cosi_1.2.1.tar
After unzipping it with tar xfp cosi_package.tar, I try to run make as stated in the README within the newly created directory cosi_1.2. Unfortunately, I get a lot of errors such as
coalescent.a(historical.o): In function `historical_process_pop_event':
historical.c:(.text+0x5c7): undefined reference to `log'
coalescent.a(historical.o): In function `historical_next_exp':
historical.c:(.text+0x76a): undefined reference to `exp'
../cosi_rand/random.a(ranbinom.o):ranbinom.c:(.text+0x702): more undefined references to `log' follow
collect2: ld returned 1 exit status
make[1]: *** [coalescent] Error 1
make[1]: Leaving directory `/home/myname/Desktop/cosi_1.2/cosi'
make: *** [all] Error 2
The MAKEFILE in the problematic sub-directory looks like this:
PACKAGE := coalescent
BINFILES := coalescent.c
SKIPFILES :=
ARFILE := $(PACKAGE).a
BINS := $(BINFILES:.c=)
PREFILES := $(wildcard *.c)
CFILES := $(filter-out $(SKIPFILES),$(PREFILES))
LIBFILES := $(filter-out $(BINFILES),$(CFILES))
OFILES := $(LIBFILES:.c=.o)
DFILES := $(CFILES:.c=.d)
FOO := $(ARFILE)(
BAR := )
AFILES := $(addprefix $(FOO), $(OFILES))
AFILES := $(addsuffix $(BAR), $(AFILES))
CC := gcc
CFLAGS := $(DEBUG) -O3 -Wall -ansi
all : $(BINS)
# rm *.d; rm *.o
install : $(BINS)
rm *.d; rm *.o
.PHONY : cleaninstall
cleaninstall :
rm $(BINS)
$(ARFILE) : $(AFILES)
$(AR) cr $(ARFILE) $(?:.c=.o)
$(RM) $(?:.c=.o)
$(BINS) : % : %.o $(ARFILE)
ranlib $(ARFILE)
$(CC) $(CFLAGS) -lm -v -o $# $#.o $(ARFILE) ../cosi_rand/random.a
%.d: %.c
#$(SHELL) -ec '$(CC) -MM $(CPPFLAGS) $< \
| sed '\''s/\($*\)\.o[ :]*/coalescent.a(\1.o) $# : /g'\'' > $#; \
[ -s $# ] || rm -f $#'
-include $(DFILES)
Obviously, all the errors are missing mathematical functions. Hence I tried adding -lm to CFLAGS but it didn't help. Any suggestions what I could do?
-lm is a linker flag. It should appear at the end of the linker command:
$(CC) -v -o $# $#.o $(ARFILE) ../cosi_rand/random.a -lm
Apparently some compilers permit -l to appear anywhere. I still haven't found out which ones do, but my GCC wants them at the end, and in reverse order of dependency: if random.a needs libm, then libm should be linked in after random.a.
I also removed $(CFLAGS) from the linker command because you should pass linker options, not compiler options, when linking.
The linker searches for dependencies in the order they are on the command line. So when you ask the linker to link with a library (with e.g. -lm) then the linker will see if there is anything that depends on the library. If there isn't then the library is discarded.
To solve this problem it's recommended that you should always put libraries after all source/object files.
Note: This dependency order is also used between libraries, so if you have a library A that depends on library B, then you need to place A before B on the command line. This of course makes it hard if you have two libraries that depend on each other.
Related
I'm trying to compile my code on OSX El Capitan. This is my Makefile
TARGET = proj_name
CC = gcc
# compiling flags
CFLAGS = -std=c99 -Wall -I.
LINKER = gcc -o
# linking flags
LFLAGS = -Wall -I. -lm
SRCDIR = src
OBJDIR = obj
BINDIR = bin
SOURCES := $(wildcard $(SRCDIR)/*.c)
INCLUDES := $(wildcard $(SRCDIR)/*.h)
OBJECTS := $(SOURCES:$(SRCDIR)/%.c=$(OBJDIR)/%.o)
rm = rm -f
$(BINDIR)/$(TARGET): $(OBJECTS)
#$(LINKER) $# $(LFLAGS) $(OBJECTS)
#echo "Linking complete!"
$(OBJECTS): $(OBJDIR)/%.o : $(SRCDIR)/%.c
#$(CC) $(CFLAGS) -c $< -o $#
#echo "Compiled "$<" successfully!"
.PHONEY: clean
clean:
#$(rm) $(OBJECTS)
#echo "Cleanup complete!"
.PHONEY: remove
remove: clean
#$(rm) $(BINDIR)/$(TARGET)
#echo "Executable removed!"
I keep getting the following error while compiling on El Capitan
ld: can't open output file for writing: bin/proj, errno=2 for architecture x86_64
I understand that its a linker issue, but if someone could help me amending the Makefile, it would really help.
Errno 2 means (google for something like errno list):
#define ENOENT 2 /* No such file or directory */
bin/proj is relative path.
Looking at the Makefile, the most likely cause seems to be, bin directory simply does not exist. ld will not try create it if it is not there. To fix, add
mkdir -p $(BINDIR)
before $(LINKER) line (-p switch allows creating a path if it does not exist, which in this case prevents error if bin already exists).
A side note: Another common cause with relative paths is, that working directory is not what you think it is, when ld is run. Adding command like pwd to before $(LINKER) command would help troubleshooting this. But looking at Makefile, this probably is not the reason here.
I have a bit of a huge Makefile that basically works as I want it to.
Issue: The problem I'm having is that the makefile only checks if the first .o needs updating and not if any others do. I'm not sure what part of my makefile is in error.
Context: I have project structure like this:
quendor
src
main.c
options.c
quendor.h
Makefile
When my Makefile builds, it constructs a build directory and things look as follows:
quendor
build
src
main.d
main.o
options.d
options.o
src
main.c
options.c
quendor.h
Makefile
To See the Problem: Now let's say I don't change my main.c but I do change my options.c file. In that case, when I run make again I get this:
make: 'build/./src/main.o' is up to date.
I'm not sure if this is because it's building into a build/src directory rather than just build as I intended.
Here is the full Makefile and I'm including all of it just because I'm not sure what might be a problem and I don't want to make unwarranted assumptions.
.PHONY : all clean
NAME := quendor
PLATFORM := windows
CC := gcc
LINK := gcc
BUILD_DIR ?= ./build
SRC_DIR ?= ./src
ifeq ($(PLATFORM), windows)
TARGET ?= quendor.exe
else
TARGET ?= quendor
endif
ifeq ($(CC), gcc)
CFLAGS += -std=c11 -Wall -Wextra -Wpedantic -Wconversion -Wmissing-prototypes -Wshadow -MMD -MP
LDFLAGS +=
OPT +=
endif
SRCS := $(wildcard $(SRC_DIR)/*.c)
OBJS := $(SRCS:%.c=$(BUILD_DIR)/%.o)
DEPS := $(OBJS:%.o=%.d)
MKDIR_P ?= #mkdir -p $(dir $#)
-include $(DEPS)
all : $(TARGET)
#echo "Building $(TARGET)"
$(TARGET) : $(OBJS)
$(LINK) $(OPT) -o $# $^ $(LDFLAGS)
$(BUILD_DIR)/%.o : %.c
$(MKDIR_P)
$(CC) $(CFLAGS) -c $< -o $#
clean:
$(RM) $(TARGET) -r $(BUILD_DIR)
This may be an artifact of how StackOverflow is parsing my Makfile but I do notice that it's showing different syntax highlighting after this line:
SRCS := $(wildcard $(SRC_DIR)/*.c)
The problem is that you are including the dependencies before you define the all rule:
-include $(DEPS)
all : $(TARGET)
If you don't specify a particular target to build on the command line (e.g., if you don't run make all) then make chooses the first explicit target in the makefile (and any included makefiles!!) as the target to build.
I assume that the dependency definitions in the $(DEPS) variable define main.o as a target and since that comes before all, it's the only thing that's run by default.
Move the -include statement later in the makefile (I typically put these all at the end of the makefile) and it will work.
I am trying to create a makefile for a new project. the project contains so far just some basic main func and some funcs declarations.
my makefile makes objects from source files, but no executable is compiled. exit with error:
mkdir -p build/./src/app/
gcc -std=gnu99 -Wall -I./src -I./src/app -I./src/include -I./src/lib -c src/app/main.c -o build/./src/app/main.o
mkdir -p build/./src/app/
gcc -std=gnu99 -Wall -I./src -I./src/app -I./src/include -I./src/lib -c src/app/Emsg.c -o build/./src/app/Emsg.o
gcc -std=gnu99 -Wall -I./src -I./src/app -I./src/include -I./src/lib -o bin/Main
gcc: fatal error: no input files
compilation terminated.
Makefile:59: recipe for target 'all' failed
make: *** [all] Error 1
this is my make file:
CFLAGS := -std=gnu99 -Wall
ifeq ($(STRIP), yes)
CFLAGS := $(CFLAGS) -s
endif
BUILD_DIR := ./build
BIN_DIR := ./bin
SRC_DIRS := ./
SRC_APPS := ./src
SRC_TESTS := ./test
SRCS_APPS := $(shell find $(SRC_APPS) -name '*.c')
SRCS_TESTS := $(shell find $(SRC_TESTS) -name '*.c')
OBJS_APPS := $(SRCS_APPS:%.c=$(BUILD_DIR)/%.o)
OBJS_TESTS := $(SRCS_TESTS:%.c=$(BUILD_DIR)/%.o)
OBJS_ALL := $(OBJS_APPS)
OBJS_ALL_TESTS := $(OBJS_ALL) $(OBJS_TESTS)
INC_APPS_DIRS := $(shell find ./src -type d)
INC_INCLUDES := src/include
INC_TESTS_DIRS := test/
INC_APPS_FLAGS := $(addprefix -I,$(INC_APPS_DIRS))
INCLUDE_ALL := $(INC_APPS_FLAGS)
CC := gcc
ifeq ($(TEST), yes)
CFLAGS := $(CFLAGS) -D TEST
OBJECTS := $(OBJS_APPS) $(OBJS_TESTS)
INCLUDE := $(INC_TESTS_LIBS_FLAGS) $(INC_TESTS_FLAGS)
DEPEND_LST := apps tests
COMP_ARGS := $(CC) $(CFLAGS) $(INCLUDE) $(OBJECTS) -L$(INC_TEST_LIBS) -o bin/Test
else
DEPEND_LST := apps
COMP_ARGS := $(CC) $(CFLAGS) $(INCLUDE_ALL) $(OBJECTS) -o bin/Main
endif
# All
all: $(DEPEND_LST)
$(COMP_ARGS)
#Tests
tests: $(OBJS_TESTS)
$(BUILD_DIR)/%.o: %.c
$(MKDIR_P) $(dir $#)
$(CC) $(CFLAGS) $(INCLUDE_ALL) -c $< -o $#
# Apps
apps: $(OBJS_APPS)
$(BUILD_DIR)/%.o: %.c
$(MKDIR_P) $(dir $#)
$(CC) $(CFLAGS) $(INCLUDE_ALL) -c $< -o $#
# Clean
clean:
$(RM) -r $(BUILD_DIR)
# not sure what these two lines do..
-include $(DEPS)
MKDIR_P ?= mkdir -p
I'm simply running make.
files hierarchy is:
src dir
app dir (contains main.c and more files)
include dir (contains some .h files)
lib dir (empty)
test dir (contains another main.c file)
Makefile file
Install GNU remake and run remake -X.
It will put you into a debugger and then you can run step to see step by step what the makefile is doing. Here is that applied to your Makefile:
$ remake -X
Reading makefiles...
Updating makefiles...
Updating goal targets...
-> (/tmp/so/Makefile:45)
all: apps
remake<0> step
File 'all' does not exist.
File 'apps' does not exist.
Must remake target 'apps'.
Successfully remade target file 'apps'.
<- (/tmp/so/Makefile:56)
apps
remake<1> where
=>#0 apps at Makefile:56
#1 all at Makefile:45
remake<3> x OBJS_APPS
Makefile:17 (origin: makefile) OBJS_APPS := ...
See the link for videos. Or https://github.com/rocky/remake for some screen shots
Make's output presents the commands it runs. For a serial build, at least, this unambiguously communicates what command produced each diagnostic message emitted. In your case, the command that caused the error immediately preceeds it in the output:
gcc -std=gnu99 -Wall -I./src -I./src/app -I./src/include -I./src/lib -o bin/Main
So what's wrong with that? Why, exactly what the diagnostic says: it doesn't specify any input files to operate upon. No C source files to compile, no object files or libraries to link. Nothing from which to build the designated output file.
Supposing that you've presented a complete makefile that produces the problem for you, that command must come from an attempt to build target all via this rule:
all: $(DEPEND_LST)
$(COMP_ARGS)
That's a bit suspicious on its face, because an all target typically provides only a prerequisite list, not a recipe. Each prerequisite that may need to be built would then have its own rule. But it's not inherently wrong to provide a recipe, and we need to consider the recipe itself to determine the nature of your problem. In this case, we have suspicious point #2: the recipe is specified entirely via a single variable. But I already knew that, because I had to trace through that to identify this rule as the source of the error in the first place.
In particular, the only place where the text bin/Main appears in the makefile is in this else block:
else
DEPEND_LST := apps
COMP_ARGS := $(CC) $(CFLAGS) $(INCLUDE_ALL) $(OBJECTS) -o bin/Main
endif
That indeed provides the command line variable referenced by the all target (and by nothing else), and it matches up cleanly with the command that causes the error. And what do we find when we match the bits of the command line to the variables from which that version of COMP_ARGS is built? We find that all the bits are covered by variables other than OBJECTS, which evidently expands to nothing (you can even see the separate leading and trailing space characters around its empty value). And why does OBJECTS expand to an empty value? Because it is never set when that branch of the conditional is exercised.
Personally, I would be inclined to rewrite the whole makefile to be more idiomatic and to rely less on GNU make extensions, but the simplest way forward would probably be to put an appropriate definition of the OBJECTS variable in the else block I pointed out.
I am trying to build a static library with mixed c and fortran code. When building the fortran files, I receive this error for each of my fortran files, but not the c files.
make: Circular file0.F90 <- file0.F90.o dependency dropped.
mpif90 -c -O2 -o "file0.F90.o" "file0.F90"
The Makefile I am using is below. My rule for F90 files is the same as for c files, so I am not sure why it should have this behaviour?
CC = mpicc
FC = mpif90
TARGET=libpxn
FCFLAGS = -O2 -fPIC
CFLAGS = -O2 -fPIC -lm -Wall
CPPFLAGS = $(CFLAGS)
SRCS = $(wildcard *.F90) $(wildcard *.c)
OBJS = $(patsubst %, %.o, $(SRCS))
# Rules
all: static
static: $(OBJS)
ar rcs $(TARGET).a $(OBJS)
%.c.o: %.c
$(CC) -c $(CFLAGS) -o "$#" "$<"
%.F90.o: %.F90
$(FC) -c $(FCFLAGS) -o "$#" "$<"
clean:
#printf "Cleaning: \n"
#find . -type f -name '*.o' -print0 | xargs -0 -I % sh -c 'printf "% "; rm -f %'
rm -f $(TARGET).so $(TARGET).a
I tried also with gnu compilers with the same result. Any ideas why this is happening?
.c is a built-in suffix, meaning at the very least there is one built-in rule defined as %.c: which will stop make from applying match anything rules (%:) to files ending with .c.
Make has no idea about .F90 on the other hand, so when it reaches the prerequisites of your %.F90.o rule, it will try to apply the match anything rule %: %.o which results in file0.F90: file0.F90.o, and a circular dependency.
The quick and dirty solution is to simply add an empty pattern rule for .F90
%.F90:
The "correct" way (IMHO) to handle this would be to rewrite your makefile to conform to the built-in implicit rules
TARGET := libpxn.a
CC := mpicc
FC := mpif90
FFLAGS := -O2 -fPIC
CFLAGS := -O2 -fPIC -Wall
ARFLAGS := rcs
CSRCS := $(wildcard *.c)
FSRCS := $(wildcard *.F90)
OBJS := $(CSRCS:.c=.o) $(FSRCS:.F90=.o)
.PHONY: all clean
all: $(TARGET)($(OBJS))
%.o: %.F90
$(COMPILE.F) $(OUPUT_OPTION) $<
%.F90:
clean:
$(info "Cleaning:")
$(RM) $(TARGET)
Make has a built-in rule for archives so you can just specify ARFLAGS and use libname(objects) as a prerequisite (IIRC if you're using GNU ar you don't need s as it'll always make an index).
The F90 recipe is copied from make's built-in rule for .F, in fact if you use .F as a fortran suffix instead of .F90 you won't even need this rule.
If you have two source files with the same stem (say foo.c and foo.F90) you'll either have to split the sources into two subdirectories (recommended), or go back to your original plan of the double suffix (you'll need to provide both rules again in that case).
I've rewritten clean as the objects are intermediate files now and will be deleted automatically after they are added to the archive.
I'm trying to compile my code on OSX El Capitan. This is my Makefile
TARGET = proj_name
CC = gcc
# compiling flags
CFLAGS = -std=c99 -Wall -I.
LINKER = gcc -o
# linking flags
LFLAGS = -Wall -I. -lm
SRCDIR = src
OBJDIR = obj
BINDIR = bin
SOURCES := $(wildcard $(SRCDIR)/*.c)
INCLUDES := $(wildcard $(SRCDIR)/*.h)
OBJECTS := $(SOURCES:$(SRCDIR)/%.c=$(OBJDIR)/%.o)
rm = rm -f
$(BINDIR)/$(TARGET): $(OBJECTS)
#$(LINKER) $# $(LFLAGS) $(OBJECTS)
#echo "Linking complete!"
$(OBJECTS): $(OBJDIR)/%.o : $(SRCDIR)/%.c
#$(CC) $(CFLAGS) -c $< -o $#
#echo "Compiled "$<" successfully!"
.PHONEY: clean
clean:
#$(rm) $(OBJECTS)
#echo "Cleanup complete!"
.PHONEY: remove
remove: clean
#$(rm) $(BINDIR)/$(TARGET)
#echo "Executable removed!"
I keep getting the following error while compiling on El Capitan
ld: can't open output file for writing: bin/proj, errno=2 for architecture x86_64
I understand that its a linker issue, but if someone could help me amending the Makefile, it would really help.
Errno 2 means (google for something like errno list):
#define ENOENT 2 /* No such file or directory */
bin/proj is relative path.
Looking at the Makefile, the most likely cause seems to be, bin directory simply does not exist. ld will not try create it if it is not there. To fix, add
mkdir -p $(BINDIR)
before $(LINKER) line (-p switch allows creating a path if it does not exist, which in this case prevents error if bin already exists).
A side note: Another common cause with relative paths is, that working directory is not what you think it is, when ld is run. Adding command like pwd to before $(LINKER) command would help troubleshooting this. But looking at Makefile, this probably is not the reason here.