g++ the order of static library matters? - c++

Question

I have been struggling all day for this problem. I use some libraries in my project and I always got some compilation errors complaining that undefined reference.
The relevant files are as follows:
encode.cc//the main file
url_codec.h//the header of the libraries, got some function definition in it
libimageenc.a
libmbpicenc.a
liburlaes.a
liburldecode.a
The makefile is like:
cflags = -Wall -O2 -fPIC
libpath=./libs/
libs+=$(libpath)liburlaes.a
libs+=$(libpath)liburldecode.a $(libpath)libimageenc.a $(libpath)libmbpicenc.a
cxx = g++
bin = encode
all: $(bin)
srcs = $(shell ls *.cc *.cpp)
objs = $(srcs:%.cc=%.o)
$(bin):${objs}
$(cxx) $(cflags) $(inc) -o $# ${objs} ${libs}
$(objs):%.o:%.cc
$(cxx) $(cflags) $(inc) -c -o $# $<
clean:
rm -f *.o
rm -f *.bak
rm -f $(bin)
The g++ compiler complains that:
g++ -Wall -O2 -fPIC -o encode encode.o ./libs/liburlaes.a ./libs/liburldecode.a ./libs/libimageenc.a ./libs/libmbpicenc.a
./libs/liburldecode.a(url_codec.o): In function `url_codec::offpic_url_decode_func(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, int&)':
url_codec.cc:(.text+0x18da): undefined reference to `uuid_unparse'
./libs/liburldecode.a(crypto_aes.o): In function `encode_aes':
crypto_aes.cc:(.text+0x4e): undefined reference to `AES_cbc_encrypt'
./libs/liburldecode.a(crypto_aes.o): In function `decode_aes':
crypto_aes.cc:(.text+0xae): undefined reference to `AES_cbc_encrypt'
./libs/liburldecode.a(crypto_aes.o): In function `init_aes_encrypt_key':
crypto_aes.cc:(.text+0xf3): undefined reference to `AES_set_encrypt_key'
./libs/liburldecode.a(crypto_aes.o): In function `init_aes_decrypt_key':
crypto_aes.cc:(.text+0x143): undefined reference to `AES_set_decrypt_key'
collect2: ld returned 1 exit status
But all these function are well defined in liburlaes.a as shown by nm -C
nm -C liburlaes.a | grep -i 'aes'
decode_byaes.o:
U AES_cbc_encrypt
U AES_set_decrypt_key
U AES_set_encrypt_key
00000060 T decode_byaes
00000000 T encode_byaes
00000110 T init_byaes_decrypt_key
000000c0 T init_byaes_encrypt_key
U decode_byaes
U encode_byaes
U init_byaes_decrypt_key
U init_byaes_encrypt_key
Things won't get better by moving the liburlaes.a to the end of libs, the output is exactly as above. And move libimageenc backward will make it worse, with more symbols claimed undefined:
libs+=$(libpath)liburldecode.a $(libpath)libimageenc.a $(libpath)libmbpicenc.a
libs+=$(libpath)liburlaes.a
So, how can I fix this?
UPDATES
I tried to put the liburlaes.a in both side, but it doesn't work, I wrap the libaray with '**' to emphasize :
g++ -Wall -O2 -fPIC -o encode encode.o **./libs/liburlaes.a** ./libs/liburldecode.a ./libs/libimageenc.a ./libs/libmbpicenc.a **./libs/liburlaes.a**
./libs/liburldecode.a(url_codec.o): In function `url_codec::offpic_url_decode_func(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, int&)':
url_codec.cc:(.text+0x18da): undefined reference to `uuid_unparse'
./libs/liburldecode.a(crypto_aes.o): In function `encode_aes':
crypto_aes.cc:(.text+0x4e): undefined reference to `AES_cbc_encrypt'
./libs/liburldecode.a(crypto_aes.o): In function `decode_aes':
crypto_aes.cc:(.text+0xae): undefined reference to `AES_cbc_encrypt'
./libs/liburldecode.a(crypto_aes.o): In function `init_aes_encrypt_key':
crypto_aes.cc:(.text+0xf3): undefined reference to `AES_set_encrypt_key'
./libs/liburldecode.a(crypto_aes.o): In function `init_aes_decrypt_key':
crypto_aes.cc:(.text+0x143): undefined reference to `AES_set_decrypt_key'
collect2: ld returned 1 exit status
make: *** [encode] Error 1

Answer 1

Yes, the order of libraries definitely matter. You need to put whatever uses the library first, then the library.
I have had cases where library A depends on something in library B, and library B needs something in library A, so you then need to put library A twice in the list.
The way the linker works is that it processes the object files, then reads the libraries to resolve the symbols not present in the object files. If the library has the object "files" to solve the dependency, then those parts are included. It then goes on to the next library. It doesn't "remember" what it has seen in the previous libraries.

Answer 2

How about this，just put liburlaes.a right behind the liburldecode.a.
g++ -Wall -O2 -fPIC -o encode encode.o ./libs/liburldecode.a **./libs/liburlaes.a **./libs/libimageenc.a ./libs/libmbpicenc.a