g ++静态库的顺序很重要吗？答案

【问题标题】：g++ the order of static library matters?g ++静态库的顺序很重要吗？
【发布时间】：2013-07-16 06:57:11
【问题描述】：

我整天都在为这个问题苦苦挣扎。我在我的项目中使用了一些库，但总是遇到一些编译错误，抱怨 undefined reference。

相关文件如下：

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

makefile 是这样的：

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)

g++ 编译器抱怨：

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

但所有这些函数都在 liburlaes.a 中定义良好，如 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

将liburlaes.a 移动到libs 的末尾并不会变得更好，输出与上面完全相同。并且向后移动libimageenc 会使情况变得更糟，更多的符号声称未定义：

libs+=$(libpath)liburldecode.a $(libpath)libimageenc.a $(libpath)libmbpicenc.a
libs+=$(libpath)liburlaes.a

那么，我该如何解决这个问题？

更新

我试着把liburlaes.a放在两边，但它不起作用，我用'**'包裹libaray来强调：

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

【问题讨论】：

您只需要按正确的顺序放置您的库。如果你有循环依赖，那么你可能需要指定一个库两次。
makefile 有一些普遍的问题：使用标准的变量标识符，而不是你自己的，稍微不同的——它会与自动规则混淆（CXX 不是cxx，CXXFLAGS，不是cflags)。此外，您的 objs 变量将包含 *.cpp 名称，因为您无法替换该扩展名。路径变量不应以/ 结尾。我认为$(objs) 规则包含语法错误。最后，使用一致的变量访问方式——$(…) 或${…}，不能同时使用。
@KonradRudolph ...我是 Linux 编程的新手。我以前从未在我可爱的 IDE 中使用过它。如果您对此熟悉，请查看投诉。
@zoujyjs 抱歉，这是不必要的。我在评论中添加了一些细节。
Linker order - GCC的可能重复

标签： c++ makefile g++

【解决方案1】：

是的，库的顺序绝对重要。您需要先放置使用该库的任何内容，然后再放置该库。

我遇到过库 A 依赖于库 B 中的某些内容，而库 B 需要库 A 中的某些内容的情况，因此您需要将库 A 两次放入列表中。

链接器的工作方式是处理目标文件，然后读取库以解析目标文件中不存在的符号。如果库具有解决依赖关系的对象“文件”，则包含这些部分。然后它继续到下一个库。它不会“记住”它在以前的库中看到的内容。

【讨论】：

@PaulR 这是一些我并不真正了解依赖关系的库。但是看看抱怨，liburldecode.a 使用了一些在liburlaes.a 中定义的函数。目前没有其他问题，请问如何先解决这个问题，只是把liburlaes.a放在后面不起作用！
是的，我把liburlaes.a放在两边，输出非常好！查看我的更新。
而 liburlaes 肯定包含您需要的功能？据我所知，它不是一个“标准”库，所以我无法说。
发现缺少其他库。由于这是一个特定问题，此处未列出缺少的库。而且答案比问题本身更有价值。

【解决方案2】：

这样怎么样，把 liburlaes.a 放在 liburldecode.a 后面就行了。

 g++ -Wall -O2 -fPIC  -o encode encode.o  ./libs/liburldecode.a **./libs/liburlaes.a **./libs/libimageenc.a ./libs/libmbpicenc.a

【讨论】：