linux - 如何设置一个.so库搜索其他.so库的路径？

Question

我有一个 libA.so 依赖于 libB.so，它位于 ../libB/(来自 libA.c)。我正在尝试以无需设置任何环境变量的方式进行编译。我有:

    cc -std=c99 -c -fPIC -I../libB/ -Wall libA.c
    cc -std=c99 -shared libA.o -L../libB -lB -o libA.so

这编译得很好。当我运行一个使用 dlopen 加载 libA 的程序时，我得到:

dyld: Library not loaded: libB.so
  Referenced from: libA/libA.so
  Reason: image not found
Trace/BPT trap: 5

所以 libA 在运行时没有找到 libB。我发现这个解决方案可以更改 Mac OS X 上的运行时路径:

install_name_tool -change libB.so @loader_path/../libB.so libA.so

但我想找到一个适用于 OS X 和 Linux 的解决方案。同样，我试图让最终用户尽可能少地做，所以我不希望他们必须设置环境变量，而且我必须使用 cc(对我来说是 Apple LLVM 4.2 版(clang-425.0 .27)(基于 LLVM 3.2svn)，而且我希望它也能在 Linux 上运行，所以大概 cc=gcc 在那里)。

编辑 我的问题可能比我意识到的更复杂。我在 C 中制作这个动态库，但试图从 python 中使用它。我可以在 python 中使用 libB.so(它没有依赖项)没问题，当我从 python 中加载 libA.so 时它找到了它(见上面的错误)，只是在那个时候 libA.so 意识到它没有'不知道在哪里可以找到 libB.so。如果我在下面正确理解你的答案，解决方案取决于在编译可执行文件时设置链接器路径，在我的例子中是在 python 中。

难道我编译libA.so的时候没有办法告诉libB.so去哪里找？之后我可以在 OSX 上使用 install_name_tool 来完成它，但是有没有一种方法可以在 OSX 和 Linux 上使用编译器？

Answer 1

底线是您的最终可执行文件必须知道您的库所在的位置。您可以通过两种方式(1)导出包含库路径的LD_LIBRARY_PATH，或者(2)使用rpath 这样你的可执行文件就知道在哪里可以找到你的库。导出 LD_LIBRARY_PATH 通常看起来像这样:

LD_LIBRARY_PATH=/path/to/your/lib:${LD_LIBRARY_PATH}
export LD_LIBRARY_PATH

我更喜欢使用 rpath。要使用 rpath 正常编译您的库(下面的示例是我的扩展测试函数库 libetf.so)

gcc -fPIC -Wall -W -Werror -Wno-unused -c -o lib_etf.o lib_etf.c
gcc -o libetf.so.1.0 lib_etf.o -shared -Wl,-soname,libetf.so.1

然后要编译使用该库的可执行文件，您编译为对象，然后使用作为链接器选项给出的 rpath 链接该对象。在您的案例中，您将为 libA.so 和 libB.so 提供路径。构建我的 testso 可执行文件:

gcc -O2 -Wall -W -Wno-unused -c -o testetf.o testetf.c
gcc -o testso testetf.o -L/home/david/dev/src-c/lib/etf -Wl,-rpath=/home/david/dev/src-c/lib/etf -letf

使用 ldd 确认可执行文件已正确找到您的库:

$ ldd testso
        linux-vdso.so.1 (0x00007fffd79fe000)
        libetf.so.1 => /home/david/dev/src-c/lib/etf/libetf.so.1 (0x00007f4d1ef23000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f4d1eb75000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f4d1f126000)

注意 libetf.so.1指向/home/david/dev/src-c/lib/etf/libetf.so.1.