linker tells me it can't resolve symbols, but

问题:

I am trying to compile a simple test app using a library I've written. This compiles and runs fine on other machines.

I have libroller.so available at /usr/lib. I'm compiling a main.cpp as such:

g++ -g3 -Wall -I"../../" -lrt -lroller -o rap main.o

It complains of numerous errors such as:

/....../main.cpp:51: undefined reference to `Log::i(char const*, ...)'

However, I know that these exist in this so:

nm -Ca /usr/lib/libroller.so | grep "Log::i"            
00000000001f5d50 T Log::i(char const*, ...)
0000000000149530 W Log::i(std::string const&)

Both are 64 bit:

file /usr/lib/libroller.so           
/usr/lib/libroller.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped

file main.o   
main.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

Unlike GCC and ld can't find exported symbols...but they're there! I'm pretty sure these symbols are defined. The same .so works with another using some of the same symbols.

EDIT/ANSWER: The order of objects is important. Placing main.o before the libraries was necessary. I'm guessing the linker had no unresolved symbols to deal with until it got to main.o -- which was the last object in its list. I'm still a little confused as to why this worked on other machines for many months...

回答1:

Change:

g++ -g3 -Wall -I"../../" -lrt -lroller -o rap main.o

to:

g++ -g3 -Wall main.o -lroller -lrt -o rap 

Link order matters (and the -I is redundant in this instance).

回答2:

Consider changing the sequence of library and main.o:

g++ -g3 -Wall -I"../../" -o rap main.o -lrt -lroller

Have a look at this post: Why does the order in which libraries are linked sometimes cause errors in GCC?

回答3:

Your question is a dup of this one, and has the same answer: order of libraries on link line matters.