链接两个"名字完全一样"的【动态库】,你会怎么处理?

时间:2022-06-02 00:17:32

链接两个"名字完全一样"的【动态库】,你会怎么处理?

【目录】

  • 第一个动态库文件
  • 应用程序
  • 第二个动态库文件
  • 错误做法:直接给它改名
  • 正解:patchelf 工具
  • One More Thing

在Linux应用的开发过程中,直接利用现成的第三方库(俗称:*)来完成自己的业务功能,是很常见的事情。

不知道你是否遇到这样的场景:应用程序中需要使用两个动态库里的不同功能的函数,但是这两个动态库的作者发生心灵感应了,居然起了完全一样的动态库名字,这该如何是好?

具体来说面对的问题是:在编译可执行程序的时候,通过gcc编译参数的-lXXX就可以动态链接一个动态库。

但是,现在你想链接两个动态库,它们的名字是一样的!!怎么办?

第一个动态库文件

现在,假设我们在开发一个机器人应用程序,需要用到一个第三方动态库中的算法。

这个库的源码很简单,如下:

  1. //第一个动态库源文件RobotMath.c:
  2. doublefunc0(doublearg)
  3. {
  4. doubleret=arg+arg;
  5. returnret;
  6. }
  7. doublefunc1(doublearg1,doublearg2)
  8. {
  9. doubleret=arg1+arg2;
  10. returnret;
  11. }

动态库的编译命令是:

  1. $gcc-m32-fPIC--shared-olibRobotMath.so-Wl,--soname,libRobotMath.soRobotMath.c

以上这些属性都比较常见,请注意其中的 -Wl,--soname,libRobotMath.so,它用来指定生成的动态库的 SONAME,一般用于动态库的版本管理中。

为了方便起见,这里就不加版本信息了。

执行了 gcc 指令之后,就得到了一个动态库文件:libRobotMath.so。

可以通过 patchelf 这个工具(在Ubuntu系统中,可以通过apt-get直接安装),来查看一下这个动态库文件的 SONAME :

  1. $patchelf--print-sonamelibRobotMath.so
  2. libRobotMath.so//SONAME

第2行打印出来的就是所谓的 SONAME。

你也可以测试一下,指定其他的 SONAME,例如:

$ gcc -m32 -fPIC --shared -o libRobotMath.so -Wl,--soname,libRobotMath-1.2.3.so RobotMath.c

$ patchelf --print-soname libRobotMath.so

libRobotMath-1.2.3.so // SONAME

以上就是第一个动态库,已经交代清楚了,下面再来看一下最简单的应用程序。

应用程序

  1. //可执行程序源文件:main.c
  2. externdoublefunc0(doublearg);
  3. externdoublefunc1(doublearg1,doublearg2);
  4. intmain(intargc,char*agv[])
  5. {
  6. doublearg=1.1;
  7. doubleresult0=func0(arg);
  8. printf("result0=%lf\n",result0);
  9. doublearg1=1.1,arg2=2.2;
  10. doubleresult1=func1(arg1,arg2);
  11. printf("result1=%lf\n",result1);
  12. return0;
  13. }

这个代码简直是幼儿园水平,不多解释,直接编译(假设已经把动态库复制到main.c同一个文件夹中了):

  1. $gcc-m32-omainmain.c-lRobotMath-L./-Wl,-rpath=./

执行:

  1. $./main
  2. result0=2.200000
  3. result1=3.300000

完美!

第二个动态库文件

问题来了:现在应用程序还需要实现另外一个复杂的算法,本着偷懒的精神,终于在另外一个机器人算法相关的库中找到了这个算法。

  1. //第二个动态库源文件RobotMath.c:
  2. doublefunc2(doublearg1,doublearg2,doublearg3)
  3. {
  4. doubleret=arg1*arg2*arg3;
  5. returnret;
  6. }
  7. //编译指令
  8. $gcc-m32-fPIC--shared-olibRobotMath.so-Wl,--soname,libRobotMath.soRobotMath.c

但是坑爹的是,这个算法库输出的动态库名称居然也是 libRobotMath.so !

与第一个算法库的文件名同名同姓,看来这个名字太招人喜欢了。

如果这个作者直接起一个其它的名字,那就啥事都没有了。

假如: 名字叫 libRobotUltra.so,那么只需要直接复制过来,然后在编译执行程序时,直接链接 -lRobotUltra 就可以了。

错误做法:直接给它改名

既然如此,我们是否可以直接给它改名呢?尝试一下:

  1. $mvlibRobotMath.solibRobotMath2.so

然后把libRobotMath2.so复制到应用程序的目录下,并在main.c中,调用这个库中的算法函数 func2。

  1. externdoublefunc2(doublearg1,doublearg2,doublearg3);
  2. intmain(intargc,char*agv[])
  3. {
  4. //之前的其它代码
  5. //...
  6. doublearg3=1.1,arg4=2.2,arg5=3.3;
  7. doubleresult2=func2(arg3,arg4,arg5);
  8. printf("result2=%lf\n",result2);
  9. return0;
  10. }

编译一下试试:

  1. $gcc-m32-omainmain.c-lRobotMath-lRobotMath2-L./-Wl,-rpath=./
  2. /tmp/ccDGqFkl.o:Infunction`main':
  3. main.c:(.text+0xb4):undefinedreferenceto`func2'
  4. collect2:error:ldreturned1exitstatus

报错:找不到 func2 这个函数。

但是libRobotMath2.so这个库中明明已经有这个函数啊,不信你看:

  1. $readelf-slibRobotMath2.so|grepfunc2
  2. 8:0000052a69FUNCGLOBALDEFAULT11func2
  3. 51:0000052a69FUNCGLOBALDEFAULT11func2

为啥 gcc 还找不到呢?

看来,很粗鲁地直接给第二个动态库文件强行改名,不是解决问题的正确思路!

正解:patchelf 工具

还记得在第一个库中,我们使用 patchelf 这个小工具来查看动态库的 SONAME 吗?

继续用它来查看下被我们改名后的 libRobotMath2.so:

  1. $patchelf--print-sonamelibRobotMath2.so
  2. libRobotMath.so

SONAME 依然是原来的名称,说明通过mv指令改名,只是改变了外表,并没有改变它的内心。

如果你熟悉文件系统,就会知道:mv 指令只是修改了库文件在 inode 节点中的名字,而库文件实际内容所存储的 block 存储空间中,一点都没有变化。

动态库是一个ELF格式的文件,操作系统在加载动态库的时候,是根据ELF格式的标准,对文件的内容进行一层一层解析的。

可以参考很久之前写的一篇文章:Linux系统中编译、链接的基石-ELF文件:扒开它的层层外衣,从字节码的粒度来探索。

patchelf 这个工具,就提供了这样的功能:查看或修改动态库文件的内部信息,包括:SONAME, 依赖的其他动态库,rpath 路径信息等等。

  1. $patchelf-h
  2. syntax:patchelf
  3. [--set-interpreterFILENAME]
  4. [--page-sizeSIZE]
  5. [--print-interpreter]
  6. [--print-soname]Prints'DT_SONAME'entryof.dynamicsection.RaisesanerrorifDT_SONAMEdoesn'texist
  7. [--set-sonameSONAME]Sets'DT_SONAME'entrytoSONAME.
  8. [--set-rpathRPATH]
  9. [--remove-rpath]
  10. [--shrink-rpath]
  11. [--print-rpath]
  12. [--force-rpath]
  13. [--add-neededLIBRARY]
  14. [--remove-neededLIBRARY]
  15. [--replace-neededLIBRARYNEW_LIBRARY]
  16. [--print-needed]
  17. [--no-default-lib]
  18. [--debug]
  19. [--version]
  20. FILENAME

我们可以使用--set-soname这个参数,来把它的 SONAME 修改一下:

  1. $patchelf--set-sonamelibRobotMath2.solibRobotMath2.so

第一个 libRobotMath2.so,是设置的 SONAME 名称;

第二个 libRobotMath2.so,是指定修改哪一个动态库文件的 SONAME;

修改之后,再检查一下是否修改正确了:

  1. $patchelf--print-sonamelibRobotMath2.so
  2. libRobotMath2.so

Bingo!SONAME 已经被正确修改了。

再次编译一下可执行程序:

  1. $gcc-m32-omainmain.c-lRobotMath-lRobotMath2-L./-Wl,-rpath=./

没有报错!

执行一下:

  1. $./main
  2. result0=2.200000
  3. result1=3.300000
  4. result2=7.986000

问题解决了!

One More Thing

什么?你说这样的问题是千年等一回?是为赋新词强说愁?那说明走过的路还不是足够的长。

记得大概是2015年的时候,开发一个网关,在硬件出来之前需要在Ubuntu (x86)平台上进行模拟。

为了便于跨平台,选择了 glib 库,但是对其中的小部分源码进行了二次开发。

但是Ubuntu的桌面系统是基于GTK的(底层使用的就是glib库),也就是说操作系统在启动时已经加载了系统目录下的 glib库。

那么我们的应用程序在编译时,的确可以链接到自己二次开发的glib库(放在本地文件夹),但是在执行时,一直加载不成功,就是因为动态库的名字冲突问题导致的。

最后没办法,只好利用 patchelf 工具,对动态库的名称,包括 SONAME 进行改写,这样才解决问题。

原文链接:https://mp.weixin.qq.com/s/FCe9nzSRkIsV-bGzqbiDIg