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的一句话：该文件与vendor/lib旁边的libbar.so}存在。两者实际上都是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 ++依赖权 - 我当然可以使用-Wl,-rpath。）

但我不禁觉得应该有一种方法可以在不使用环境变量/ -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缓存，它具有较少的区分效果。

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

1 个答案: