构建依赖多层.so共享库的C++可执行文件时RPATH丢失问题求助

问题根本原因 #

该现象属于ELF链接体系的设计规则，并非异常问题：

• RPATH是存储在ELF文件中的运行时搜索路径，仅在程序启动阶段供动态加载器（ld-linux.so）查找依赖库时使用
• 编译链接阶段的静态链接器（ld）完全不会读取依赖共享库的RPATH字段，也不存在RPATH继承逻辑，因此libB中定义的RPATH不会自动传递到依赖它的libA、也不会被最终的可执行文件链接过程使用，这就是你链接时调用到系统路径下错误liblapack.so的核心原因。

符合要求的解决方案（仅修改各包链接参数、不改动现有构建流程） #

按适用优先级排序：

• 方案1：在构建最终可执行文件时添加-Wl,-rpath-link,/你的自定义liblapack.so路径参数。-rpath-link是专门给静态链接器使用的参数，仅作用于编译链接阶段查找间接依赖的场景，不会写入最终ELF文件，运行时仍然会使用libB的RPATH查找正确的liblapack.so，完全不破坏各包的独立维护逻辑。
• 方案2：在libA的链接脚本中新增自动提取libB RPATH的逻辑，无需硬编码路径。示例参数如下：

  -Wl,-rpath=$(readelf -d /path/to/libB.so | grep 'RPATH' | awk -F'[][]' '{print $2}')
  

  该逻辑会自动读取libB当前的RPATH并写入libA的RPATH字段，libB修改RPATH时libA会自动同步，符合各自配置自行维护的要求。
• 方案3：如果所有包的安装路径层级固定，使用$ORIGIN相对路径配置RPATH。比如三个包都安装在同一个prefix的bin、lib目录下，可在libB、libA的链接参数中统一添加-Wl,-rpath,'$ORIGIN'（根据实际层级调整），无需硬编码家目录绝对路径，适配性更强。

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