linux - 为什么我不能用 LD_LIBRARY_PATH 覆盖动态库的搜索路径？

Question

编辑:我解决了这个问题，解决方案如下。

我正在专用于科学计算的共享计算集群中构建代码，因此我只能控制我的主文件夹中的文件。虽然我以 fftw 为例，但我想了解具体原因，为什么我尝试设置 LD_LIBRARY_PATH 不起作用。

我像这样在我的主文件夹中构建 fftw 和 fftw_mpi 库

./configure --prefix=$HOME/install/fftw --enable-mpi --enable-shared
make install

构建良好，但在 install/fftw/lib 中，我发现新构建的 libfftw3_mpi.so 链接到错误版本的 fftw 库。

$ ldd libfftw3_mpi.so |grep fftw
  libfftw3.so.3 => /usr/lib64/libfftw3.so.3 (0x00007f7df0979000)

如果我现在尝试将 LD_LIBRARY_PATH 设置为正确指向该目录，它仍然会选择错误的库:

$ export LD_LIBRARY_PATH=$HOME/install/fftw/lib
$ ldd libfftw3_mpi.so |grep fftw
    libfftw3.so.3 => /usr/lib64/libfftw3.so.3 (0x00007f32b4794000)

只有当我显式使用 LD_PRELOAD 时，我才能覆盖此行为。不过，我认为 LD_PRELOAD 不是合适的解决方案。

$ export LD_PRELOAD=$HOME/install/fftw/lib/libfftw3.so.3 
$ ldd libfftw3_mpi.so |grep fftw
   $HOME/install/fftw/lib/libfftw3.so.3 (0x00007f5ca3d14000)

这是我所期望的，在 Ubuntu 桌面上进行的一个小测试，我首先将 fftw 安装到/usr/lib，然后用 LD_LIBRARY_PATH 覆盖此搜索路径。

$ export LD_LIBRARY_PATH=
$ ldd q0test_mpi |grep fftw3
    libfftw3.so.3 => /usr/lib/x86_64-linux-gnu/libfftw3.so.3
$ export LD_LIBRARY_PATH=$HOME/install/fftw-3.3.4/lib
$ ldd q0test_mpi |grep fftw3
    libfftw3.so.3 => $HOME/install/fftw-3.3.4/lib/libfftw3.so.3

简而言之:为什么 libfft3_mpi 库仍然找到错误的动态 fftw3 库？这个搜索路径在哪里以优先于 LD_LIBARY_PATH 的方式硬编码？为什么在另一台计算机上不是这种情况？

如果这很重要，我正在使用英特尔编译器 13.1.2、mkl 11.0.4.183 和 openmpi 1.6.2。

编辑:感谢您的所有回答。在这些帮助下，我们能够将问题隔离到 RPATH，并且从那里，集群支持能够找出问题。我接受了第一个答案，但两个答案都很好。

之所以如此难以弄清楚，是因为我们不知道编译器实际上是包装脚本，向编译器命令行添加东西。以下是支持人员回复的一部分:

[The] compilation goes through our compiler wrapper. We do RPATH-ing by default as it helps most users in correctly running their jobs without loading LD-LIBRARY_PATH etc. However we exclude certain library paths from default RPATH which includes /lib, /lib64 /proj /home etc. Earlier the /usr/lib64 was not excluded by mistake (mostly). Now we have added that path in the exclusion list.

Answer 1

来自 http://man7.org/linux/man-pages/man8/ld.so.8.html

When resolving shared object dependencies, the dynamic linker first inspects each dependency string to see if it contains a slash (this can occur if a shared object pathname containing slashes was specified at link time). If a slash is found, then the dependency string is interpreted as a (relative or absolute) pathname, and the shared object is loaded using that pathname.

If a shared object dependency does not contain a slash, then it is searched for in the following order:

o (ELF only) Using the directories specified in the DT_RPATH dynamic section attribute of the binary if present and DT_RUNPATH attribute does not exist. Use of DT_RPATH is deprecated.

o Using the environment variable LD_LIBRARY_PATH. Except if the executable is a set-user-ID/set-group-ID binary, in which case it is ignored.

o (ELF only) Using the directories specified in the DT_RUNPATH dynamic section attribute of the binary if present.

o From the cache file /etc/ld.so.cache, which contains a compiled list of candidate shared objects previously found in the augmented library path. If, however, the binary was linked with the -z nodeflib linker option, shared objects in the default paths are skipped. Shared objects installed in hardware capability directories (see below) are preferred to other shared objects.

o In the default path /lib, and then /usr/lib. (On some 64-bit archiectures, the default paths for 64-bit shared objects are /lib64, and then /usr/lib64.) If the binary was linked with the -z nodeflib linker option, this step is skipped.

• 与 readelf readelf -d libfftw3_mpi.so您可以检查您的库是否在动态部分包含这样的属性。

• 与 export LD_DEBUG=libs您可以调试用于查找库的搜索路径

• 与 chrpath -r<new_path> <executable> rpath可以改变