问题
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.
来源：https://stackoverflow.com/questions/8382153/linker-tells-me-it-cant-resolve-symbols-but-theyre-there