Question

在CentOS 7.2上，我使用g ++ 4.8.5构建了一个无法运行的应用程序，因为它找不到{strong>确实存在在其runpath中存在的库。我很确定它在两个星期前已经奏效。是什么原因造成的？

$ ./app
./app: error while loading shared libraries: libhdf5.so.9: cannot open shared object file: No such file or directory

$ ldd ./app | grep libhdf5
    libhdf5.so.9 => not found

$ readelf app -d | grep path
 0x000000000000001d (RUNPATH)            Library runpath: [/opt/ProductName/lib:/opt/ProductName/lib/private]

$ ll /opt/ProductName/lib/libhdf5.so*
lrwxrwxrwx. 1 fotechd fotechd      16 Oct 26 14:38 /opt/ProductName/lib/libhdf5.so -> libhdf5.so.9.0.0
lrwxrwxrwx. 1 fotechd fotechd      16 Oct 26 14:38 /opt/ProductName/lib/libhdf5.so.9 -> libhdf5.so.9.0.0
-rwxr-xr-x. 1 fotechd fotechd 3316074 Oct 26 14:35 /opt/ProductName/lib/libhdf5.so.9.0.0

设置LD_LIBRARY_PATH可以临时修复：

$ LD_LIBRARY_PATH=/opt/ProductName/lib ./app
...
OK

Answer 1

我已经能够解决这一问题。对我来说，这是因为未找到的库是一个间接库，而runpath实际上不能解决间接依赖关系。我通过将附加的rpath链接器选项传递给编译器，使用runpath而不是-Wl,--disable-new-dtags进行了修复。

这里有一个很好而详尽的解释：How to set RPATH and RUNPATH with GCC/LD?

Answer 2

为了找到共享对象，dlopen（）以此顺序搜索以下内容：

链接二进制文件时使用-rpath选项设置为ld（请参见《实用程序参考》）的运行时库搜索路径
由LD_LIBRARY_PATH环境变量指定的目录
目录

似乎dlopen()没有检查RUNPATH。

http://www.qnx.com/developers/docs/6.5.0SP1.update/com.qnx.doc.neutrino_lib_ref/d/dlopen.html

为什么会忽略运行路径？

2 个答案: