强制使用没有 LD_RUN_PATH 的共享库的绝对路径

Question

我正在尝试将本地安装的共​​享库 (./vendor/lib/libfoo.so) 与我的二进制文件 ./bar 链接。不幸的是，我的任何尝试都没有生成带有libfoo.so 的绝对路径的链接。因此我需要使用

LD_LIBRARY_PATH=vendor/lib ./bar

运行它，我想避免。 ldd bar 给我看这个：

    linux-vdso.so.1 =>  (0x00007ffed5fd8000)
    libbar.so.2 => not found
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fb9ea787000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb9ea47d000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb9ea267000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb9e9e9d000)
    /lib64/ld-linux-x86-64.so.2 (0x000055f326761000)

关于libbar.so.2 的一句话：该文件与libbar.so 一起存在（在vendor/lib 中）。两者实际上都是libhts.so.1.6 的符号链接。该文件也存在，并且是实际的共享库。

这是我尝试过的不同方法：

FULL_PATH="$(pwd -P)/vendor/lib"

g++ -o bar bar.o -Lvendor/lib -lfoo        # 1
g++ -o bar bar.o -L$FULL_PATH -lfoo        # 2
g++ -o bar bar.o $FULL_PATH/libfoo.so      # 3
g++ -o bar bar.o $FULL_PATH/libfoo.so.1.6  # 4

所有这些变体都产生相同的ldd 输出，甚至最后一行（ld 是否坚持使用最高版本的库？）。

我发现完成这项工作的唯一方法是使用

LD_RUN_PATH=$FULL_PATH g++ -o bar bar.o -Lvendor/lib -lfoo

（我不能使用-rpath，因为我的g++ 版本不理解这个论点，我使用g++ 而不是ld 来获得正确的libstdc++ 依赖项——我可以使用@ 987654340@ 当然。）

但我不禁觉得应该有一种方法可以在不使用环境变量/-rpath的情况下完成这项工作。我找到了an answer specifically referencing symlinks to libraries，但不幸的是它对我没有帮助（参见上面的尝试 4）。

这是在 Ubuntu 16.04、g++ 5.4.0、GNU ld 2.26.1 上，以防万一。

Answer 1

听起来您可能在安装后没有更新ldconfig 缓存 你的共享库在非标准位置/what/ever/vendor/lib:-

sudo ldconfig /what/ever/vendor/lib

在您这样做之前，运行时链接器不会意识到 libfoo.so 是 在/what/ever/vendor/lib，即使是，除非你在运行时通过 LD_LIBRARY_PATH 环境变量。

顺便说一句，你的g++ 版本的缺点不是它 无法识别-rpath。这只是一个链接器 (ld) 选项， 绝不是 GCC 前端选项。所以-Wl,-rpath=/what/ever/vendor/lib 是 将非标准运行时库路径附加到您的常规方法 程序以避免依赖ldconfig缓存或LD_LIBRARY_PATH

对于不寻常的链接，使用-rpath 可能会更好 而不是扩展ldconfig 缓存，这具有较少的区分效果。