最近遇到一个问题，有两个底层依赖模块，分别是dep1和dep2。在dep1中有调用dep2的代码。本地开发完毕后，合入分支编译报错 提示符号未定义。但是，本地编译是正常的，在新的分支编译就会报错。于是，开始排查。
第一步发现，本地对应的分支dep1和dep2是使用动态库连接的，合入的分支的dep1和dep2是使用静态库连接的。问题大致因此导致的。
进一步查看Makefile，检查链接规则，发现在可执行文件链接的时候 是先链接 -ldep2 再链接-ldep1。问题进一步明确了，是由于连接的顺序导致的。新的代码是中dep1依赖dep2，但是链接的顺序是先dep2，然后dep1。问题的范围缩小，大概是因为链接的顺序导致的。
查了一下gcc ld的链接规则，ld查询符号的规则是顺序往后找，发现未定义的符号就放在一个集合u中。ld的规则并不会往前去查找，比如在dep1中发现了未定义的符号func(定义在dep2中), 此时已经扫描过dep2了，不会再往前去查找了。因此，就会出现符号找不到的问题。
也就是说对于日常命令行编译命令，一般从左到右分别是可执行文件 -->> 高级库 -->>底层库 ，避免循环依赖；越是底层的库，越是往后面写，可以参考下述命令通式：
g++ ... obj($?) -l(上层逻辑lib) -l(中间封装lib) -l(基础lib) -l(系统lib) -o $@
自我分析的非常合理，写个例子验证下。目录的结构如下，func_a.c 和 func_b.c是两个底层库，func_a中的函数调用func_b中的函数（func_a 依赖于func_b），然后分别将func_a和func_b打包为静态库，进行编译。通过执行不同的编译顺序，查看是否可以编译成功。
tree
.
|-- func_a.c
|-- func_b.c
`-- main.cpp
几个文件内容如下：
$ cat func_a.c
#include <stdio.h>
int func_b();
int func_a()
{
printf("enter func_a");
func_b();
return 0;
}%
$ cat func_b.c
#include <stdio.h>
int func_b()
{
printf("enter func_b");
return 0;
}%
$ cat main.cpp
#include <stdio.h>
int func_a();
int main()
{
func_a();
return 0;
}%
写一个构建脚本
# 生成.o文件
g++ -c func_a.c
g++ -c func_b.c
g++ -c main.cpp
# 打包为静态库
ar -rc func_a.a func_a.o
ar -rc func_b.a func_b.o
# 链接
g++ -o main_a1 main.o func_a.a func_b.a # 执行成功，编译出main_a1
# 交换一下链接静态库的顺序后，编译失败
g++ -o main_a2 main.o func_b.a func_a.a # 执行失败
那问题到这步就已经定位了，问题的原因是静态库的链接顺序导致的。
那么，怎么解决这个问题呢？想到了几个办法，分别是：
- 交换一下顺序，让更高层的模块放在前面
- 提取耦合公共依赖，形成一个新的库，链接的时候，放在最后面。
- 看看gcc能不能显示的指定一下（或者自己寻找一下依赖关系）
进一步分析一下每个办法的利弊：
- 第一个办法，肯定是最简单的。但是，如果出现了dep1和dep2相互依赖的情况，要如何解决的？究竟要把谁放在前面？为了应对这种情况，也是有个操作，就是先链接dep1，再链接dep2，再次链接dep1。类似于下面命令这种，虽然比较硬核，但是也没毛病，可以解决问题。
g++ xxx -ldep1 -ldep2 -ldep1
-
第二个办法，也是一个办法。相互独立的模块，理论上不应该相互依赖。
-
第三个办法，查了一下gcc可以通过指定参数start-group和end-group做到这一点。这应该是最优雅的办法了。
# 无论什么顺序，都可以编译成功
g++ -o main_a3 main.o -Wl,--start-group func_b.a func_a.a -Wl,--end-group
g++ -o main_a4 main.o -Wl,--start-group func_a.a func_b.a -Wl,--end-group
还有一个问题，为什么另外一个分支上，用动态库链接就没问题呢？为什么动态库就不需要制定链接的顺序？
写了一个脚本验证了一下，动态库果然不会出现依赖顺序的问题。无论先链接libfunca 还是libfuncb，程序都是正常的运行。
g++ func_a.c -o libfunca.so -shared -fPIC
g++ func_b.c -o libfuncb.so -shared -fPIC
g++ -o main1_so main.cpp -L. -lfunca -lfuncb # 先liba 再libb 成功
g++ -o main2_so main.cpp -L. -lfuncb -lfunca # 先libb 再liba 成功
好吧，看到动态库似乎不会出现这种问题。那问题就到这里结案了。
小结：
- 静态库链接会有顺序问题，链接顺序要从高层到底层来写。尽量避免顺序问题。
- 如果已经出现了，无法避免，可以利用gcc的参数
start-group和end-group让链接器自己寻找顺序
关于静态库和动态库连接顺序的另外一个问题：
- 如果
liba.a和libb.b中有同一个符号，那么链接的时候，会怎么样？ - 如果
liba.so和libb.so中有同一个符号，那么链接的时候，会怎么样？
$ cat func_a.c
int test()
{
printf("func A :: test() \n");
return 0;
}%
$ cat func_b.c
#include <stdio.h>
int test()
{
printf("func B :: test() \n");
return 0;
}%
$ cat main.cpp
#include <stdio.h>
int test();
int main()
{
test();
return 0;
}%
分贝打包为静态库和动态库，进行构建：
静态库：
g++ -c func_a.c
g++ -c func_b.c
g++ -c main.cpp
ar -rc func_a.a func_a.o
ar -rc func_b.a func_b.o
g++ -o main_a1 main.o func_a.a func_b.a
g++ -o main_a2 main.o func_b.a func_a.a
动态库：
g++ func_a.c -o libfunca.so -shared -fPIC
g++ func_b.c -o libfuncb.so -shared -fPIC
g++ -o main1_so main.cpp -L. -lfunca -lfuncb
g++ -o main2_so main.cpp -L. -lfuncb -lfunca
静态库连接的时候，会提示错误。动态库则不会。动态库链接的时候会找放在最前面的库的符号最为匹配对象。因此，不同的链接顺序，程序的输出也不一样。
g++ -o main_a1 main.o func_a.a func_b.a
func_b.a(func_b.o): In function `test()':
func_b.c:(.text+0x1a): multiple definition of `test()'
func_a.a(func_a.o):func_a.c:(.text+0x1f): first defined here
collect2: error: ld returned 1 exit status
g++ -o main_a2 main.o func_b.a func_a.a
func_a.a(func_a.o): In function `func_a()':
func_a.c:(.text+0x14): undefined reference to `func_b()'
collect2: error: ld returned 1 exit status
g++ -o main1_so main.cpp -L. -lfunca -lfuncb
g++ -o main2_so main.cpp -L. -lfuncb -lfunca
./main1_so
func A :: test()
./main2_so
func B :: test()
- 小结
对于同名的符号，如果使用静态库链接，会提示重定义的错误；如果使用动态库连接，会匹配第一个遇到的库中的符号；
网友评论