|
|
|
|
公众号矩阵

原来编译链接还有这么多套路

不知道大家平时编程过程中使用动态链接库的情况多不多,如果一个程序引用了无数个动态链接库,那就有可能引入符号冲突的问题。

作者: 程序喵大人来源: 程序喵大人|2021-01-14 05:08

本文转载自微信公众号「程序喵大人」,作者程序喵大人 。转载本文请联系程序喵大人公众号。

大家好,我是程序喵。

不知道大家平时编程过程中使用动态链接库的情况多不多,如果一个程序引用了无数个动态链接库,那就有可能引入符号冲突的问题,问题如下:

想象中

实际上

下面我们尝试解决它:

最开始介绍下g++基本命令参数:

  1. g++ 
  2. -c <file> 编译源文件,但是不进行链接 
  3. -o <file> 指定输出文件的名字 
  4. -s        strip,移除符号信息 
  5. -L <dir>  指令搜索链接库的路径 
  6. -l <lib>  指定要链接的链接库 
  7. -shared   产生动态目标文件 

先来看一段代码:

  1. #include <stdio.h> 
  2.  
  3. void DoThing() { printf("work \n"); } 

再定义一个简单的main.cc程序:

  1. #include <stdio.h> 
  2.  
  3. void DoThing(); 
  4.  
  5. int main() { 
  6.     printf("start \n"); 
  7.     DoThing(); 
  8.     printf("finished \n"); 
  9.     return 0; 

编译这两个文件,并分别打包成静态库:

  1. g++ -c work.cc -o work.o 
  2. ar rc libwork.a work.o 
  3. g++ -c main.cc -o main.o 
  4. ar rc libmain.a main.o 

现在将这两个静态库链接成一个可执行文件,注意链接器如果发现当前库中使用了没有被定义的符号,它只会向后查找,因此,最低级别没有其它依赖的库应该放在最右边,如果出现了符号冲突问题,链接器会使用最左边的符号。

如果这样进行链接:

  1. $ g++ -s -L. -o main.exe -lwork -lmain 
  2. ./libmain.a(main.o): In function `main': 
  3. main.cc:(.text+0x11): undefined reference to `DoThing()' 
  4. collect2: error: ld returned 1 exit status 

链接失败,因为main库里的DoThing符号没有被定义,链接器向后查找,没有找到对应的符号定义,这里更改下链接库的顺序:

  1. g++ -s -L. -o main.exe -lmain -lwork 
  2. $ ./main.exe 
  3. start 
  4. work 
  5. finished 

链接成功。

现在写一个简单的容易产生符号冲突的文件conflict.cc:

  1. #include <stdio.h> 
  2.  
  3. void DoThing() { printf("conflict \n"); } 

编译并打包成静态库:

  1. g++ -c conflict.cc -o conflict.o 
  2. ar rc libconflict.a conflict.o 

如果按这样的顺序链接成一个可执行程序:

  1. $ g++ -s -L. -o main.exe -lmain -lwork -lconflict 
  2. $ ./main.exe 
  3. start 
  4. work 
  5. finished 

如果稍微更改一下链接的顺序:

  1. $ g++ -s -L. -o main.exe -lmain -lconflict -lwork 
  2. $ ./main.exe 
  3. start 
  4. conflict 
  5. finished 

这里发现顺序的不同导致了程序输出内容不同,究其原因就是那潜在的符号冲突。

现在再试试动态库,先介绍如何使用动态库:

  1. $ rm libconflict.a 
  2. $ g++ -shared conflict.o -o libconflict.so 
  3. $ g++ -s -L. -o main.exe -lmain -lconflict 
  4. $ LD_LIBRARY_PATH=. ./main.exe 
  5. start 
  6. conflict 
  7. finished 

现在再引用一个中间层在动态链接库中调用conflict的文件layer.cc

  1. #include <stdio.h> 
  2. void DoThing(); 
  3. void DoLayer() { 
  4.     printf("layer \n"); 
  5.     DoThing(); 

并把layer和conflict打包成一个动态链接库:

  1. $ g++ -c layer.cc -o layer.o 
  2. $ g++ -shared layer.o conflict.o -o libconflict.so 

然后更新main.c程序,main里面调用layer,layer里调用conflict:

  1. #include <stdio.h> 
  2. void DoLayer(); 
  3. int main() { 
  4.     printf("start \n"); 
  5.     DoLayer(); 
  6.     printf("finished \n"); 
  7.     return 0; 

编译链接执行:

  1. $ g++ -c main.cc -o main.o 
  2. $ ar rc libmain.a main.o 
  3. $ g++ -s -L. -o main.exe -lmain -lconflict 
  4. $ LD_LIBRARY_PATH=. ./main.exe 
  5. start 
  6. layer 
  7. conflict 
  8. finished 

正常输出,没啥问题,现在再把之前的work.cc也塞到main.cc中,观察下冲突:

  1. #include <stdio.h> 
  2. void DoThing(); 
  3. void DoLayer(); 
  4. int main() { 
  5.     printf("start \n"); 
  6.     DoThing(); 
  7.     DoLayer(); 
  8.     printf("finished \n"); 
  9.     return 0; 

把work.o和main.o打包成一个库,之后和conflict链接成一个可执行程序,运行:

  1. $ g++ -c main.cc -o main.o 
  2. $ ar rc libmain.a main.o work.o 
  3. $ g++ -s -L. -o main.exe -lmain -lconflict 
  4. $ LD_LIBRARY_PATH=. ./main.exe 
  5. start 
  6. work 
  7. layer 
  8. work 
  9. finished 

这里输出了两个work,正常情况下第二个work应该输出conflict,怎么解决呢?可以考虑使用-fvisibility=hidden来隐藏内部的符号,链接库内部使用的符号把它隐藏掉,不让它被导出,外部也不会改变它的调用路径。

先使用nm看一下libconflict.so里面的符号:

  1. $ nm -CD libconflict.so 
  2.                  w _ITM_deregisterTMCloneTable 
  3.                  w _ITM_registerTMCloneTable 
  4. 000000000000065a T DoLayer() 
  5. 0000000000000672 T DoThing() 
  6. 0000000000201030 B __bss_start 
  7.                  w __cxa_finalize 
  8.                  w __gmon_start__ 
  9. 0000000000201030 D _edata 
  10. 0000000000201038 B _end 
  11. 0000000000000688 T _fini 
  12. 0000000000000528 T _init 
  13.                  U puts 

如果把符号隐藏掉,

  1. $ g++ -fvisibility=hidden -c layer.cc -o layer.o 
  2. $ g++ -fvisibility=hidden -c conflict.cc -o conflict.o 
  3. $ g++ -shared layer.o conflict.o -o libconflict.so 
  4. 再使用nm看一下libconflict.so里面的符号: 
  5. $ nm -CD libconflict.so 
  6.                  w _ITM_deregisterTMCloneTable 
  7.                  w _ITM_registerTMCloneTable 
  8. 0000000000201028 B __bss_start 
  9.                  w __cxa_finalize 
  10.                  w __gmon_start__ 
  11. 0000000000201028 D _edata 
  12. 0000000000201030 B _end 
  13. 0000000000000618 T _fini 
  14. 00000000000004c0 T _init 
  15.                  U puts 

这样的话main函数肯定不能调用DoLayer啦,因为DoLayer符号没有暴露出来:

  1. $ g++ -s -L. -o main.exe -lmain -lconflict 
  2. ./libmain.a(main.o): In function `main': 
  3. main.cc:(.text+0x16): undefined reference to `DoLayer()' 
  4. collect2: error: ld returned 1 exit statu 

那怎么暴露出来特定符号呢,直接看代码,改动了layer.cc:

  1. #include <stdio.h> 
  2. void DoThing(); 
  3. __attribute__ ((visibility ("default"))) void DoLayer() { 
  4.     printf("layer \n"); 
  5.     DoThing(); 

再编译链接运行看看结果:

  1. $ g++ -fvisibility=hidden -c layer.cxx -o layer.o 
  2. $ g++ -shared layer.o conflict.o -o libconflict.so 
  3. $ g++ -s -L. -o main.exe -lmain -lconflict 
  4. $ LD_LIBRARY_PATH=. ./main.exe 
  5. start 
  6. work 
  7. layer 
  8. conflict 
  9. finished 

发现已经是我们期待的结果啦,符号冲突的问题因此被解决。

是不是感觉很麻烦,难道每个要暴露的符号都要加上__attribute__这种修饰吗,这里其实可以写一个export文件,告诉编译器要导出的所有符号有哪些。

  1. export.txt 
  2.  
  3.  global: *DoLayer*; 
  4.  local: *; 
  5. }; 
  6. g++ -Wl,--version-script=export.txt -s -shared layer.o conflict.o -o libconflict.so 

但是这种方式只有在gcc中才可以被使用,我在clang中尝试使用但是失败啦,所以为了兼容性不建议使用这种方式,还是消停的使用__attribute__来解决符号冲突问题吧。

【编辑推荐】

  1. CentOS 7 源码编译安装Python3.9
  2. 在流水线中使用容器进行编译构建
  3. AMD Zen 3 用英特尔编译器后性能如何
  4. 《C深度解析》第三章 存储类、生命周期、作用域、链接域
  5. 【夏曹俊】零基础学习在Linux上编译调试C++项目视频课程
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

数据湖与数据仓库的分析实践攻略

数据湖与数据仓库的分析实践攻略

助力现代化数据管理:数据湖与数据仓库的分析实践攻略
共3章 | 创世达人

3人订阅学习

云原生架构实践

云原生架构实践

新技术引领移动互联网进入急速赛道
共3章 | KaliArch

30人订阅学习

数据中心和VPDN网络建设案例

数据中心和VPDN网络建设案例

漫画+案例
共20章 | 捷哥CCIE

209人订阅学习

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微