gcc使用Wl,rpath解决so库版本冲突

ref:https://www.dyxmq.cn/linux/gcc-option-wl-rpath.html

一、 问题描述

最近工作中遇到了一个问题&＃xff1a;项目需要合入其他部门的模块&＃xff0c;但是其中的一个共用共享库被更新了。因为项目很大&＃xff0c;如果直接在我们的环境中替换更新这个库&＃xff0c;很有可能会影响到其他模块。祖传的代码流传了差不多20年&＃xff0c;涉及的模块也十分之多&＃xff0c;贸然升级的风险很难评估。但是不替换这个库第三方模块又跑不起来&＃xff0c;一度头痛。

刚开始是想到了以下几 个方法&＃xff1a;

1. 设置LD_LIBRARY_PATH环境变量&＃xff0c;修改查找路径的优先级。

2. 修改so库名

对于第一种方法是有效的&＃xff1a;在程序目录下加个lib目录&＃xff0c;然后export LD_LIBRARY_PATH把当前路径放到第一搜索顺序&＃xff0c;能解决这个问题。但是&＃xff0c;环境变量时当前所有程序共享的&＃xff0c;其他程序的搜索目录也是这里第一&＃xff0c;所以这里的结果就和直接升级库没有区别。同样&＃xff0c;修改/etc/ld.so.conf的原理也是一样。

第二种方法本来是认为比较靠谱的&＃xff0c;但是测试发现共享库并不是根据文件名来的&＃xff0c;修改库名无效。so库内部还有个真实的名字&＃xff0c;可以通过 readelf -d lib*.so 来查看&＃xff1a;

> readelf /usr/lib/libau.so -d Dynamic section at offset 0x2c88 contains 29 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000e (SONAME) Library soname: [libau.so.2]

所以上面两种方法就被排除了&＃xff0c;后面查了很久也没有找到合适的办法&＃xff0c;崩溃。。。

最后去请教大佬就被告知了可以使用 -Wl,-rpath 选项来解决这个问题&＃xff0c;试了一下确实可以。

二、-Wl,-rpath和-Wl,-rpath-link选项

2.1 -Wl,-rpath

加上 -Wl,-rpath 选项的的作用就是指定“程序运行时”的库搜索目录&＃xff0c;是一个链接选项&＃xff0c;生效于设置环境变量之前。

我们已经知道&＃xff0c;共享库的查找顺序为&＃xff1a;

1. LD_LIBRARY_PATH 环境变量的目录

2. ld.so.conf 高速缓冲文件中的目录

3. 系统的默认库目录如 /lib, /lib64 等

而 -Wl,-rpath 可以让程序在第一步搜索之前先搜索它所指定的目录&＃xff0c;通过一个例子来说明&＃xff1a;

// add.h int add(int i, int j); // add.c #include "add.h" int add(int i, int j) { return i &＃43; j; } // main.c #include #include "add.h" int main() { printf("1 &＃43; 2 &＃61; %d\n", add(1, 2)); return 0; }

add.h和add.c用于生成一个so库&＃xff0c;实现了一个简单的加法&＃xff0c;main.c中引用共享库计算1 &＃43; 2&＃xff1a;

# 编译共享库 gcc add.c -fPIC -shared -o libadd.so # 编译主程序 gcc main.o -L. -ladd -o app

编好后运行依赖库&＃xff1a;

> ldd app linux-vdso.so.1 (0x00007ffeb23ab000) libadd.so &＃61;> not found libc.so.6 &＃61;> /lib/x86_64-linux-gnu/libc.so.6 (0x00007febb7dd0000) /lib64/ld-linux-x86-64.so.2 (0x00007febb83d0000 > ./app ./app: error while loading shared libraries: libadd.so: cannot open shared object file: No such file or directory

可以看到&＃xff0c;libadd.so这个库是没有找到的&＃xff0c;程序也无法运行&＃xff0c;要运行它必须要把当前目录加到环境变量或者库搜索路径中去。

但是如果在链接的时候加上 -Wl,-rpath 选项之后&＃xff1a;

> gcc -Wl,-rpath&＃61;&＃96;pwd&＃96; main.o -L. -ladd -o app > ldd app linux-vdso.so.1 (0x00007fff8f4e3000) libadd.so &＃61;> /data/code/c/1-sys/solib/libadd.so (0x00007faef8428000) libc.so.6 &＃61;> /lib/x86_64-linux-gnu/libc.so.6 (0x00007faef8030000) /lib64/ld-linux-x86-64.so.2 (0x00007faef8838000) > ./app 1 &＃43; 2 &＃61; 3

依赖库的查找路径就找到了&＃xff0c;程序能正常运行。

2.2 -Wl,rpath-link

-Wl,rpath-link 是设置编译链接时候的顺序&＃xff0c;例如app运行依赖libadd.so&＃xff0c;但是libadd.so又依赖libadd_ex.so&＃xff0c;rpath-link 就是指定libadd_ex.so的路径。和 -Wl,rpath 相比工作的时间不同&＃xff0c;一个在链接期间&＃xff0c;一个在运行期间。