不知道大家平时编程过程中使用动态链接库的情况多不多,如果一个程序引用了无数个动态链接库,那就有可能引入符号冲突的问题,问题如下:
想象中
实际上
下面,我们尝试解决它。
最开始介绍下g++基本命令参数:
g++-c
先来看一段代码:
#include
再定义一个简单的main.cc程序:
#include
编译这两个文件,并分别打包成静态库:
g++ -c work.cc -o work.oar rc libwork.a work.og++ -c main.cc -o main.oar rc libmain.a main.o
现在将这两个静态库链接成一个可执行文件,注意链接器如果发现当前库中使用了没有被定义的符号,它只会向后查找,因此最低级别没有其它依赖的库应该放在最右边,如果出现了符号冲突问题,链接器会使用最左边的符号。
如果这样进行链接:
$ g++ -s -L. -o main.exe -lwork -lmain./libmain.a(main.o): In function `main':main.cc undefined reference to `DoThing()'collect2: error: ld returned 1 exit status
链接失败,因为main库里的DoThing符号没有被定义,链接器向后查找,没有找到对应的符号定义,这里更改下链接库的顺序:
g++-s-L.-omain.exe-lmain-lwork$./main.exestartworkfinished
链接成功。
现在写一个简单的容易产生符号冲突的文件conflict.cc:
#include
编译并打包成静态库:
g++-cconflict.cc-oconflict.oar rc libconflict.a conflict.o
如果按这样的顺序链接成一个可执行程序:
$g++-s-L.-omain.exe-lmain-lwork-lconflict$./main.exestartworkfinished
如果稍微更改一下链接的顺序:
$g++-s-L.-omain.exe-lmain-lconflict-lwork$ ./main.exestartconflictfinished
这里发现顺序的不同导致了程序输出内容不同,究其原因就是那潜在的符号冲突。
现在再试试动态库,先介绍如何使用动态库:
$rmlibconflict.a$g++-sharedconflict.o-olibconflict.so$g++-s-L.-omain.exe-lmain-lconflict$LD_LIBRARY_PATH=../main.exestartconflictfinished
现在再引用一个中间层在动态链接库中调用conflict的文件layer.cc
#include
并把layer和conflict打包成一个动态链接库:
$g++-clayer.cc-olayer.o$ g++ -shared layer.o conflict.o -o libconflict.so
然后更新main.c程序,main里面调用layer,layer里调用conflict:
#include
编译链接执行:
$g++-cmain.cc-omain.o$arrclibmain.amain.o$g++-s-L.-omain.exe-lmain-lconflict$LD_LIBRARY_PATH=../main.exestartlayerconflictfinished
正常输出,没啥问题,现在再把之前的work.cc也塞到main.cc中,观察下冲突:
#include
把work.o和main.o打包成一个库,之后和conflict链接成一个可执行程序,运行:
$g++-cmain.cc-omain.o$arrclibmain.amain.owork.o$g++-s-L.-omain.exe-lmain-lconflict$LD_LIBRARY_PATH=../main.exestartworklayerworkfinished
这里输出了两个work,正常情况下第二个work应该输出conflict,怎么解决呢?
可以考虑使用-fvisibility=hidden来隐藏内部的符号,链接库内部使用的符号把它隐藏掉,不让它被导出,外部也不会改变它的调用路径。
先使用nm看一下libconflict.so里面的符号:
$nm-CDlibconflict.sow_ITM_deregisterTMCloneTablew_ITM_registerTMCloneTable000000000000065aTDoLayer()0000000000000672TDoThing()0000000000201030B__bss_startw__cxa_finalizew__gmon_start__0000000000201030D_edata0000000000201038B_end0000000000000688T_fini0000000000000528T_init U puts
如果把符号隐藏掉:
$g++-fvisibility=hidden-clayer.cc-olayer.o$g++-fvisibility=hidden-cconflict.cc-oconflict.o$g++-sharedlayer.oconflict.o-olibconflict.so再使用nm看一下libconflict.so里面的符号:$nm-CDlibconflict.sow_ITM_deregisterTMCloneTablew_ITM_registerTMCloneTable0000000000201028B__bss_startw__cxa_finalizew__gmon_start__0000000000201028D_edata0000000000201030B_end0000000000000618T_fini00000000000004c0T_init U puts
这样的话main函数肯定不能调用DoLayer啦,因为DoLayer符号没有暴露出来:
$g++-s-L.-omain.exe-lmain-lconflict./libmain.a(main.o):Infunction`main':main.ccundefinedreferenceto`DoLayer()'collect2: error: ld returned 1 exit statu
那怎么暴露出来特定符号呢,直接看代码,改动了layer.cc:
#include
再编译链接运行看看结果:
$g++-fvisibility=hidden-clayer.cxx-olayer.o$g++-sharedlayer.oconflict.o-olibconflict.so$g++-s-L.-omain.exe-lmain-lconflict$LD_LIBRARY_PATH=../main.exestartworklayerconflictfinished
发现已经是我们期待的结果啦,符号冲突的问题因此被解决。
是不是感觉很麻烦,难道每个要暴露的符号都要加上__attribute__这种修饰吗,这里其实可以写一个export文件,告诉编译器要导出的所有符号有哪些。
export.txt {global:*DoLayer*;local:*;};g++ -Wl,--version-script=export.txt -s -shared layer.o conflict.o -o libconflict.so
但这种方式只有在gcc中才可以被使用,我在clang中尝试使用但是失败啦,所以为了兼容性不建议使用这种方式,还是消停的使用__attribute__来解决符号冲突问题吧。
Tips
通过隐藏符号可以减小可执行程序的大小,还可以解决符号冲突问题,但有个缺点,因为隐藏了符号,线上程序运行时如果出现crash,通过堆栈信息我们看不到具体函数调用路径,给定位问题带来了困难。所以,是否需要使用这种办法,还应根据实际情况具体抉择。
原文标题:原来编译链接还有这么多套路……
文章出处:【微信公众号:嵌入式ARM】欢迎添加关注!文章转载请注明出处。
责任编辑:haq
-
嵌入式
+关注
关注
5082文章
19118浏览量
305037 -
编程
+关注
关注
88文章
3615浏览量
93715
原文标题:原来编译链接还有这么多套路……
文章出处:【微信号:gh_c472c2199c88,微信公众号:嵌入式微处理器】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
评论