I am trying to compile a project by compiling object files and then linking them together, nothing fancy:
hello.o : hello.h hello.cu
nvcc hello.cu -c -o hello.o
#...
main.o : $(objs)
nvcc *.o -o exec
When I get to the link phase, just about every method is shown to be missing and undeclared, despite the fact that nm shows that each is in fact sitting within my object files, and their names are unmangled. What is going on here?
Your final make target looks bogus: shouldn't it say:
exec : $(objs)
nvcc $(objs) -o $#
You may also need to add the CUDA libraries to the command-line (I think nvcc figures this out when you're compiling a .cu file directly, but maybe it doesn't if you just give it .o files). So, something more like this:
exec : $(objs)
nvcc $(objs) -o $# -lcuda -lcudart -lcublas
(Precisely which libraries you need depends on your code)
Ok, so my question's formulation was incorrect. In fact, the problem was that I was compiling C code like so:
hello.o : hello.h hello.cu
nvcc hello.c -c -o hello.o
#...
main.o : $(objs)
nvcc *.o -o exec
which caused nvcc to pass the .c files to gcc. When I grepped 'nm *.o' for the name of my method, I found that the object files emitted by gcc had unmangled names, while the .cu files, which were compiled by g++, expected mangled names.
My solution was to rename all the .c files in my project to .cu, although I think (but haven't tested) that leaving them as .c and calling g++ on them explicitly in the makefile should be enough.
I tried calling g++ but still got the same errors. The answer was found here:
http://forums.nvidia.com/index.php?showtopic=190973&st=0&gopid=1179661&#entry1179661
In short, function prototypes need to be correct.
Related
My working directory looks like this:
main.c
Makefile
my_memmove.h
my_memmove.c
c-timer-lib
timer.c
timer.h
My makefile looks like this:
CC := gcc
CFLAGS := -std=gnu99 -g -Wall -Wextra -Ic-timer-lib
TARGET := output
output: main.o my_memmove.o timer.o
$(CC) $(CFLAGS) main.o my_memmove.o timer.o -o $(TARGET)
main.o: main.c
gcc -c main.c
my_memmove.o: my_memmove.c my_memmove.h
gcc -c my_memmove.c
timer.o: c-timer-lib/timer.c c-timer-lib/timer.h
gcc -c c-timer-lib/timer.c -o $#
clean:
rm *.o $(TARGET)
I don't understand why I keep getting the "Makefile: No rule to make target 'timer.c', needed by 'timer.o'. Stop." error. I believe that it's because the timer.c and timer.h files can't be found.
So much confusion here! :)
First, this is definitely wrong:
$(CC) $(CFLAGS) -I main.o ...
The -I main.o tells the compiler that it should use main.o as the name of a directory to search for include files. That clearly won't work. You should remove the -I here.
On to your problem: you have to realize that there are two completely different programs at play here: make which figures out how to run commands, and the commands that are being run, in this case the compiler gcc.
The -I option is an option to the compiler so that the compiler knows where to look for header files that are included by your source code with #include.
That option means nothing to make; it doesn't understand that option. It's just some text to pass to the compiler. Make is looking for the source file timer.c and it can't find it because you haven't told make where it is.
You have to write your rule to look in the correct place, like this:
timer.o: c-timer-lib/timer.c c-timer-lib/timer.h
gcc -c c-timer-lib/timer.c -o $#
(you should always use -o $# so that your compile line puts the output file where make expects to find it, which will be put into the $# variable by make before it evaluates your recipe.)
ETA
Also, are you sure that -DUNITS="ms" is right? We can't tell without seeing how UNITS is used in the source, but I suspect you probably need an extra level of quotes here, like -DUNITS='"ms"'
Really, you are trying to do too much in this makefile. Make already knows how to correctly build object files from source files. If you don't force the issue by writing your own rules, then make's built-in rules will do the job for you. Your makefile can be written like this:
CC := gcc
CFLAGS := -std=gnu99 -g -Wall -Wextra -Ic-timer-lib -DUNITS='"ms"'
TARGET := output
$(TARGET): main.o my_memmove.o c-timer-lib/timer.o
$(CC) $(CFLAGS) $(LDFLAGS) -o $# $^ $(LDLIBS)
my_memmove.o: my_memmove.h
c-timer-lib/timer.o: c-timer-lib/timer.h
clean:
rm *.o $(TARGET)
make doesn't know which headers your source requires so you have to add the prerequisites by hand, although you can add extra rules to allow it to figure that out for itself.
I study C language in ubuntu 18.04(gcc 7.3)
When the make all command is entered, this error occurrs:
/usr/bin/x86_64-linux-gnu-ld: can not find -lkeccak
The Makefile is as follows.
CC=gcc
CFLAGS=-03 -fomit-frame-pointer -msse2avx -mavx2 -march=native -std=c99
all:
$(CC) $(CFLAGS) -c Lizard.c main.c randombytes.c sha512.c
$(CC) $(CFLAGS) -o Lizard Lizard.o main.o randobytes.o sha512.o -lkeccak
run: all
./Lizard
new:
make clean
make all
./Lizard
Currently the libkeccak.a file is in the same directory as the Makefile and
it is also in the /usr/include directory.
I do not know the solution method at all.
Please, Help me.
The -l option is for linking dynamic libraries (like libkeccak.so). Static libraries are linked into the executable already if they're in one of the "standard" directories, so there's no need to provide the option -lkeccak.
If you want to explicitly tell GCC to link a static library,
gcc -l:/path/to/libkeccak.a
I have a bunch of .cu files that use dynamic parallelism (a.cu, b.cu, c.cu.., e.cu, f.cu), and a main.c file that uses MPI to call functions from a.cu on multiple nodes. I'm trying to write a make file to compile the executable, but I keep facing the following errors:
cudafiles.o: In function `__cudaRegisterLinkedBinary_66_tmpxft_00001a84_00000000_17_cuda_device_runtime_compute_61_cpp1_ii_8b1a5d37':
link.stub:(.text+0x1fb): undefined reference to `__fatbinwrap_66_tmpxft_00001a84_00000000_17_cuda_device_runtime_compute_61_cpp1_ii_8b1a5d37'
Here is my makefile:
INCFILES=-I/usr/local/cuda-8.0/include -I/opt/mpi/mvapich2-gnu/2.2/include -I./
LIBFILES=-L/usr/local/cuda-8.0/lib64 -L/opt/mpi/mvapich2-gnu/2.2/lib
LIBS=-lcudart -lcudadevrt -lcublas_device -lmpi
ARCH=-gencode arch=compute_60,code=sm_60
NVCC=nvcc -ccbin g++
default: all
all: clean final.o
io.o: io.cpp
g++ -c -std=c++11 io.cpp
final.o: io.o a.cu b.cu c.cu d.cu e.cu f.cu main.cpp
$(NVCC) -std=c++11 $(INCFILES) $(LIBFILES) $(LIBS) -g -G -Xptxas -v -dc $(ARCH) a.cu b.cu c.cu d.cu e.cu f.cu
$(NVCC) -std=c++11 $(ARCH) $(INCFILES) $(LIBFILES) $(LIBS) -rdc=true -dlink a.o b.o c.o d.o e.o f.o io.o -o cudafiles.o
mpicxx -O3 $(INCFILES) $(LIBFILES) -c main.cpp -o main.o
mpicxx $(INCFILES) $(LIBFILES) $(LIBS) cudafiles.o a.o b.o c.o d.o e.o f.o io.o main.o -o exec
clean:
rm -rf *.o exec
The original problem reported was an undefined reference to main. This was arising from this line in the Makefile:
$(NVCC) -std=c++11 $(ARCH) $(INCFILES) $(LIBFILES) $(LIBS) -rdc=true a.o b.o c.o d.o e.o f.o io.o -o cudafiles.o
As constructed, this actually instructs nvcc to perform full/final linking. However the intent of this line was to perform the device-link step only, required when compiling with -rdc=true or -dc, and when not performing the final link with nvcc. In this case, the final link was being performed by mpicc/mpicxx. To perform the device-link step only, we need to specify -dlink. Without that switch, nvcc expects to do final linking, but fails because none of the supplied objects contain a main function. The correct solution, since we have no intent to do final link at this point, is to use the -dlink switch.
I also suggested converting everything to C++ style linking, since nvcc links that way. It might be possible to sort out a C-style link with a C++-style link, but this just seems troublesome to me. Therefore I suggested converting the only .c file (main.c) to a .cpp file, and convert from mpicc to mpicxx
The next problem that arose was undefined references to e.g. cudaSetDevice() and cudaFree(). These are part of the CUDA runtime API library ("libcudart"). When performing final link with nvcc, these are linked automatically. But since final link is being performed by mpicxx (basically a wrapper on g++), it's necessary to call out the link against that library specifically with -lcudart.
Finally, the remaining problem was a link-order problem. In a nutshell, link dependencies need to be satisfied from left to right in the linker command line. Different compilers are more or less picky about this. The final reordering changes were to specify the libraries to link against in the correct order, and also to specify these libraries at the end of the link command line, so that any dependencies on these libraries, to their left in the link command line, are satisfied.
I am modifying an old makefile in order to build a C extension for postgreSQL. The Makefile currently looks like this:
PGLIB = /usr/lib/postgresql/8.4/lib
PQINC = /usr/include/postgresql/8.4/server
CC=gcc
override CFLAGS+= $(CFLAGS_SL) -DPG_AGGREGATE
SHLIB = pg_myextlib
SRC = foo.c \
foobar.c
OBJS = foo.o \
foobar.o
all: $(OBJS)
$(CC) -shared -o $(SHLIB)$(DLSUFFIX) $(OBJS) -I$(PQINC)
cp *.so $(PGLIB)
clean:
rm -f $(SHLIB) $(OBJS)
The error I get when I run make is:
common.h:58:22: error: postgres.h: No such file or directory
Which suggests that the include path is not being added (the file exists in $PQINC).
Its a long time since I wrote the Makefile - and I haven't written many since. As an aside, I am pretty sure that 'shared' is not the gcc flag to build shared libs on Ubuntu (my current dev box) - I think the flag should be 'fPIC' - can someone confirm this?
I am runing gcc v4.4.3 on Ubuntu 10.0.4 and compiling for use with PG 8.4
Try moving the -I$(PQINC) from target all to the end of line that starts with override CFLAGS.
Placing -Isomething on the compiler line which turns object files, like those in $(OBJS), into executable will have no effect whatsoever.
You need to do it when you compile the source files.
Since your makefile doesn't explicitly show the rule for processing source files, it may well be using a default one, which is incredibly unlikely to know about PQINC.
You seem to be using the default rules to build foo.o from foo.c, which doesn't have your -I. Try adding the following rule to your Makefile:
.c.o:
$(CC) $(CFLAGS) -c $< -o $# -I$(PQINC)
Here's my Makefile:
DIR=..
ARG=$(QUERY_STRING)
MAIN=main
SRC_DIR=$(DIR)/src
BIN_DIR=$(DIR)/bin
INC_DIR=$(DIR)/inc
LIB_DIR=$(DIR)/lib
LIBS=markdown
all: $(MAIN) exec
$(MAIN): $(MAIN).o
$(LD) $^ -L $(LIB_DIR) -l $(LIBS) -o $(BIN_DIR)/$#
$(MAIN).o: $(SRC_DIR)/$(MAIN).c
$(CC) $^ -I $(INC_DIR) -o $#
exec:
$(BIN_DIR)/$(MAIN) $(ARG)
clean:
rm -f *.o core.* $(BIN)/$(MAIN)
It's clearly defined how my project is organized, so I will not explain it. It does compile without any problems, but on binary execution $(BIN_DIR)/$(MAIN) the following error appears:
../bin/main: error while loading shared libraries: rintf: cannot open shared object file: No such file or directory
make: *** [exec] Error 127
What library does rintf belong? I tried to link -lc too, but that doesn't solves the problem.
Is there something wrong with my Makefile? Or should I link something extra to $(MAIN)?
Thanks in advance for your responses.
You should essentially never link a program by invoking ld directly; always use your compiler to do the linking. It passes all sorts of extra arguments to ld to make things work. Replace the $(LD) with $(CC). Do that regardless of whether it actually fixes your problem or not.
'Tis odd that you are not getting the name of the shared object specified in the error message.
This manual page for rintf() indicates that it is declared in <math.h>; most likely, you need to add the maths library to the link line: -lm.
I would rewrite some of your makefile:
LIB1 = -lmarkdown
LIB2 = -lm
LIBS = $(LIB1) $(LIB2)
LDFLAGS = -L $(LIB_DIR)
...
$(MAIN): $(MAIN).o
$(CC) $^ $(LDFLAGS) $(LIBS) -o $(BIN_DIR)/$#
Usually, this error appears when the linker is not able to find the needed shared object (.so file).I am assuming Linux platform.
In Linux OS, you can search for the file using: find, or locate. If you can find the .so file, try to update the linker cache using ldconfig. If it did not work, check the linker configuration files under /etc/ld.conf.d/ to see if the library path is included. If you changed the configuration, don't forget to update the cache again!