含RPATH的二进制无法通过带RUNPATH的依赖查找传递依赖

问题背景 #

近期系统学习了动态链接器/加载器的工作机制、RPATH与RUNPATH的差异、直接依赖与传递依赖的查找规则等内容，此前的认知为：若可执行二进制配置了RPATH（未配置RUNPATH），动态加载器会使用该RPATH路径查找该二进制的所有依赖，包含传递依赖。但在如下依赖链路场景中，该规则并未生效：
binary(RPATH) -> libB(RUNPATH) -> libA

最小复现 #

使用如下命令构建测试样例：

g++ a.cpp -shared -fPIC -o liba.so
g++ b.cpp -shared -fPIC -o libb.so -L. -la -Wl,-rpath=/foo
g++ main.cpp -L. -lb -la -Wl,-rpath=\$ORIGIN -Wl,--disable-new-dtags

构建完成后，二进制自身的RPATH无法完成传递依赖libA的查找，执行ldd a.out的输出如下：

$ ldd a.out
    linux-vdso.so.1 (0x00007ffd2dd81000)
    libb.so => /tmp/test/./libb.so (0x00007ff0d8217000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff0d800f000)
    /lib64/ld-linux-x86-64.so.2 (0x00007ff0d8223000)
    liba.so => not found

如果移除libB中的RUNPATH配置，则可以通过二进制的RPATH正常找到libA。

待确认问题 #

• 该现象是否符合动态链接器的预期行为？官方文档仅说明：若二进制存在DT_RPATH动态段属性且不存在DT_RUNPATH属性，则使用DT_RPATH指定的目录查找依赖，而当前测试的可执行二进制本身确实不存在DT_RUNPATH段。
• 实际生产场景中，libA和libB是无法修改的第三方共享库，需要将可执行文件和依赖库部署在非标准路径下，且不希望使用patchelf修改第三方库的配置，请问LD_LIBRARY_PATH是否是解决该依赖查找问题的唯一方案？

补充说明：测试环境为Ubuntu 20.04，使用系统默认GCC工具链。

该现象是动态链接器的标准预期行为 #

你之前对RPATH作用范围的理解存在一个非常普遍的误区：RPATH不是全局覆盖整个依赖树的配置，它的查找规则和当前正在解析依赖的ELF对象强绑定，核心搜索逻辑顺序如下：

• 当动态链接器要为某个ELF对象（可执行文件或共享库）查找它的直接依赖时，第一步先检查当前正在加载依赖的这个ELF对象自身的动态段属性：
  • 如果该对象存在DT_RUNPATH条目，就仅使用这个条目里配置的路径查找它的直接依赖，查找完成后直接终止RPATH/RUNPATH层面的搜索流程，完全不会回溯上层加载者（比如主程序、依赖链更靠前的共享库）配置的RPATH
  • 只有当该对象不存在DT_RUNPATH条目时，动态链接器才会沿着依赖加载链向上回溯，使用所有上层对象配置的DT_RPATH条目查找对应依赖
    你的测试场景刚好命中了RUNPATH对上层RPATH的截断逻辑：查找libA时，当前处理的是libB的直接依赖，而构建libB时使用的-Wl,-rpath=/foo参数在Ubuntu 20.04默认工具链下会生成DT_RUNPATH而非DT_RPATH（这是binutils 2.28之后的默认行为，只有显式加--disable-new-dtags参数才会生成旧格式的DT_RPATH），因此动态链接器只会去libB写死的/foo路径下查找libA，根本不会读取主程序上配置的$ORIGIN RPATH，自然会报找不到的错误。当移除libB的RUNPATH配置后，查找libA时没有当前对象的RUNPATH截断，才会向上回溯使用主程序的RPATH完成库查找，完全符合动态链接器的设计规则。

不修改第三方库的前提下，LD_LIBRARY_PATH不是唯一解决方案 #

除了设置LD_LIBRARY_PATH环境变量，还有两个不需要改动第三方库的可行方案，可适配不同的部署场景：

• 启动程序时直接通过动态链接器传参指定库路径：不需要修改全局环境，也不需要改动任何ELF文件，直接把系统动态链接器作为程序启动入口，用--library-path参数指定库存放目录即可，示例：

  /lib64/ld-linux-x86-64.so.2 --library-path /your/deploy/lib/path /path/to/your/executable
  

  这个方案的效果和临时设置LD_LIBRARY_PATH完全一致，适合不想污染当前shell环境的单次启动或调试场景。
• 配置系统动态链接器的全局搜索路径：如果你的部署路径是固定的，可以在/etc/ld.so.conf.d/目录下新建一个配置文件，把依赖库存放的绝对路径写入文件，之后执行ldconfig刷新动态库缓存即可。这个方案是系统级生效，所有程序都可以在该路径下找到对应依赖，不需要为单个程序做特殊启动配置，适合生产环境固定路径部署的场景，运维成本最低。

如果不想做系统级配置，也不想每次启动附加参数，还有个适配性有限的方案：编译主程序时除了配置$ORIGIN的RPATH，也把所有第三方依赖的存放路径写入主程序的RPATH条目中，但这个方式在中间库自带RUNPATH截断的场景下依然不生效，本质还是需要配合前面两种方案使用。

内容的提问来源于stack exchange，提问作者user1011113