linker tells me it can't resolve symbols, but they're there?

Question

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...

Answer 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).

Answer 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?