手册   游戏   WEB   字典   单词   在线工具  

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

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

大家好, 我是程序喵.

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

想象中

实际上

下面我们尝试解决它:

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

g++

-c 编译源文件, 但是不进行链接

-o 指定输出文件的名字

-s strip, 移除符号信息

-L

指令搜索链接库的路径

-l 指定要链接的链接库

-shared 产生动态目标文件

先来看一段代码:

  1. #include
  2. void DoThing() {
  3. 	printf("work \n");	
  4. }

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

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

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

  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
  2. void DoThing() {
  3. 	printf("conflict \n");	
  4. }

编译并打包成静态库:

  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
  2. void DoThing();
  3. void DoLayer() {
  4.     printf("layer \n");
  5.     DoThing();
  6. }

并把 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
  2. void DoLayer();
  3. int main() {
  4.     printf("start \n");
  5.     DoLayer();
  6.     printf("finished \n");
  7.     return 0;
  8. }

编译链接执行:

  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
  2. void DoThing();
  3. void DoLayer();
  4. int main() {
  5.     printf("start \n");
  6.     DoThing();
  7.     DoLayer();
  8.     printf("finished \n");
  9.     return 0;
  10. }

把 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

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

  1. $ nm -CD libconflict.so
  2.                  w _ITM_deregisterTMCloneTable
  3.                  w _ITM_registerTMCloneTable
  4. 0000000000201028 B __bss_start
  5.                  w __cxa_finalize
  6.                  w __gmon_start__
  7. 0000000000201028 D _edata
  8. 0000000000201030 B _end
  9. 0000000000000618 T _fini
  10. 00000000000004c0 T _init
  11.                  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
  2. void DoThing();
  3. __attribute__ ((visibility ("default"))) void DoLayer() {
  4.     printf("layer \n");
  5.     DoThing();
  6. }

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

  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__来解决符号冲突问题吧.

来源: http://developer.51cto.com/art/202101/640779.htm


与本文相关文章

  1. 原来 FFMPEG 这么有意思
  2. 原来有这么多人不相信芬兰真的存在?
  3. 原来Android动画还能这么写
  4. 什么是通信原理? 原来这么简单
  5. 震惊！原来命令行还可以这么玩？！
  6. 原来 FFMPEG 这么有意思 (二)
  7. 关于 C++ 编译链接和模板函数
  8. 原来 Python 还有这些实用的功能和特点!
暂无,快来抢沙发吧！
更多





黑ICP备17005318号-1