引言

动态库的编译，这有什么难度，这不是手到擒来的事情吗？无非不就是：

gcc -FPIC -shared -o libxxx.so  *.o  *.c  

我若是提出这些需求场景，阁下又如何应对呢？

• 动态库A依赖其他部分提供的能力。但是却不想将内部的能力暴露出去。
• 动态库A依赖外部函数func_xxx,但是该符号即可能存在我们自己的库B中，也可能存在客户动态库C中。如何保证调用指定接口？
• 对外提供的库，如何让客户只能访问指定接口，实现其它接口的隐藏等。

至此你还能面不改色，自信的说：动态库编译简单吗？嘴角颤抖，不屈的低语：就是简单。

也有朋友可能就会说：“现实工作中怎么会有这么奇葩的要求？就是你难为人，没事找事”。但是我想说的是，这些场景真的很常见，我在工作中就遇到过，不妨听我细说。

-Wl,–exclude-libs,ALL

工作场景：当今IT行业，一个产品的输出，基本都是有多个部门相互合作，紧密配合才能实现的。而各个部门之间的常见的配合方式就是提供SDK。比如：我之前在海康是做门禁产品的。其中有一个重要功能就是人脸识别。该功能流程可以分解

视频流获取 --> 提取图片帧 --> 人脸识别算法获取唯一ID --> 比对数据库中的ID --> 放行

其中视频流获取 --> 提取图片帧是bsp团队开发，他们提供动态库libB.a，我们调用其中对应接口。人脸识别算法计算唯一ID则是研究院团队提供的算法库libC.a。比对数据库中的ID --> 放行则是我们团队的开发内容。我们对外提供libA.so。

很明显我们，我们仅仅是做门禁业务开发，总不能把BSP团队或研究院的核心能力也提供给甲方吧？否则一定要加钱的。

但是我们该怎么做呢？因为我们知道，正常编译静态库libC.so的方式，肯定会将bsp和研究院提供的能力对外开放。客户集成时，是可以直接引用到libA.a和libB.a的对外接口。代码示例如下：

//a.c
extern int printf(char* ftm,...);
int a()
{printf("i'am liba.so");return 0;
}//b.c
extern int printf(char* ftm,...);
int b()
{printf("i'am libb.so");
}//c.c
extern int a(void);
extern int b(void);int c()
{a();b();return 0;
}

编译：

yihua@ubuntu:~/test/1207$ gcc -c a.c
yihua@ubuntu:~/test/1207$ ar rcs -o libA.a a.o
yihua@ubuntu:~/test/1207$ gcc -c b.c
yihua@ubuntu:~/test/1207$ ar rcs -o libB.a b.o
yihua@ubuntu:~/test/1207$ gcc -FPIC -shared -o libC.so c.c -lA -lB -L.

符号关系：

如图所示，外部是可以通过libC.so去直接调用libA.a和libB.a的接口。

如何解决这个问题呢？

链接器为我们提供了 -Wl,–exclude-libs 参数选项：隐藏静态库文件的符号。

我们加上编译选项再试试。

yihua@ubuntu:~/test/1207$
yihua@ubuntu:~/test/1207$ gcc -FPIC -shared -o libC.so c.c -L.  -Wl,--exclude-libs,ALL -lA -lB
yihua@ubuntu:~/test/1207$

符号关系：

由图可知，libA.a 和 libB.a的内部符号已经被隐藏了。完结，撒花~~~

-Wl,-Bsymbolic

工作场景：在工作中，我们无法避免的会依赖其它动态库。比如：我司开发的SDK libA.so底层用到了mqtt通信，因此会依赖开源库libpaho-mqtt3c.so，但是我司对内部源码做了一些定制化修改；同时，我们也依赖第三方供应商的SDK libB.so,并且他们内部也采用了mqtt协议通信，同样集成了mqtt开源库,也许他们也在内部做了定制化处理。

关系如下：

分析：

情况一：当admfotaApp运行时，链接器会根据它的动态库依赖关系，加载相应的动态库。而libpaho-mqtt3c.so仅会加载一次。之后再进行符号链接时，就会出现异常。—— 加载库了非预期的库。

情况二：会导致mqtt开源库代码段被加载两次，也就是说进程中会有两套相同的符号和对应的代码段。libB.so和libA.so在进行符号链接时，可能就会出现异常。 —— 符号链接时出现问题。

示例代码如下：

//a.c
extern int printf(const char* ftm,...);
int a()
{printf("i‘am OEM a\n");
}int c()
{printf("i'am OEM c\n");
}//b.c
extern int printf(const char* ftm,...);
extern int c(void);
extern int d(void);
int b()
{printf("i‘am abup a\n");c();d();return 0;
}//c.c
extern int printf(const char* ftm,...);
int c()
{printf("i‘am abup c\n");
}//d.c
extern int printf(const char* ftm,...);
int d()
{printf("i‘am abup d\n");
}//main.c
extern int printf(const char* ftm,...);
extern int a(void);
extern int b(void);
int main()
{a();b();return 0;
}

编译如下：

gcc -c c.c
gcc -c d.c
ar -crs -o libC.a c.o d.o   // 生成静态库
gcc -FPIC -shared -o libB.so b.c -lC -L.    //从这可以看出，b.c期望时引用c.c中的c()
gcc -FPIC -shared -o libA.so a.c
gcc main.c -o main -lA -lB -lC -L.

运行：

由上可知：输出内容是非预期的。我们更新一下编译命令gcc main.c -o main -lB -lA -L.,运行结果如下：

链接库的顺序不一样，居然会有不一样的结果？这是为什么呢？有兴趣的朋友可以搜索：全局符号介入相关知识点。或参考我的一篇博客：全局符号介入引起的问题

针对该场景如何处理呢？

链接器中的-Wl,-Bsymbolic参数:告诉链接器强制使用本地的符号，也就是说，编译libB.so时，就确定符号地址。不需要等待运行时再链接。
比如我们在编译main.c时，增加该参数:

gcc -FPIC -shared -o libB.so b.c -lC -L. -Wl,-Bsymbolic
gcc main.c -o main -lA -lB -L.

输出：

完结撒花~~~。

有兴趣的同学可以通过反汇编查看增加-Wl,-Bsymbolic参数前后，libB.so的汇编内容。

总结

本文从两个实际存在的场景，向大家介绍了动态库生成过程中的一些特定需求。简单介绍了 -Wl,-Bsymbolic 和 -Wl,–exclude-libs,ALL两个链接属性及使用方式。

当然很多其它常用的参数比如：-fvisibility=hidden、-Wl,--whole-archive。有兴趣的朋友可以了解一下。

若我的内容对您有所帮助，还请关注我的公众号。不定期分享干活,剖析案例，也可以一起讨论分享。

我的宗旨：

踩完您工作中的所有坑并分享给您，让你的工作无bug，人生尽是坦途