为什么 LD_LIBRARY_PATH 不好以及加载动态库的正确方法

Question

所以，我有一个与 OpenBlas 一起运行的程序，我想编译它。链接过程如下所示：

gcc -o prog prog.o -O3 -I/opt/OpenBLAS/include -L/opt/OpenBLAS/lib -lopenblas

到目前为止一切顺利。如果我删除 -L 选项，我会在链接过程中收到错误

/usr/bin/ld: cannot find -lopenblas

使用-Leverything 链接没有错误。但是，当我尝试运行它时，出现以下错误：

./prog: error while loading shared libraries: libopenblas.so.0: cannot open shared object file: No such file or directory

如果我将环境变量LD_LIBRARY_PATH 设置为/opt/OpenBlas/lib，我可以运行程序，但是像http://xahlee.info/UnixResource_dir/_/ldpath.html 这样的许多来源认为这是一种不好的做法，我几乎可以理解所有推理。文章中提到的另一种方法（修改 ld 配置）也被认为是一种不好的做法。最后，您可以在/usr/lib 中向库添加符号链接。最后两种方法的一个大问题是您需要 sudo 访问权限。

所以我的问题是如何在不使用LD_LIBRARY_PATH 和 sudo 访问的情况下编译和运行链接到不在默认路径 (/usr/lib) 中的共享库的程序。在文章中，他们说您可以在二进制文件中“写入”以查找共享库，但我不知道该怎么做（-L 标志似乎没有这样做）。如果有人能解释这个问题，我将不胜感激，因为我一直在到处寻找并且我很困惑（一些参考资料似乎表明标志 '-L' 应该这样做，但我不适合我）。提前谢谢你。

Answer 1

将路径添加到运行时库搜索路径。

gcc -Wl,-rpath=/opt/OpenBlas/lib ...

-L 选项在链接时的作用，-rpath 选项在运行时的作用。

Answer 2

在 linux 上，也可以在 rpath 中使用 $ORIGIN 来表示应用程序的目录路径，并从那里构建相对 rpath。然后，您可以将库移动到二进制文件的已知相对路径。

gcc -o prog prog.o -O3 -I/opt/OpenBLAS/include -Wl,-rpath=\$ORIGIN/lib -L/opt/OpenBLAS/lib -lopenblas

您也可以使用库的完整路径，它将链接到：

gcc -o prog prog.o -O3 -I/opt/OpenBLAS/include /opt/OpenBLAS/lib/libopenblas.so

如果您在可执行文件上运行“ldd”，您应该会看到已编码的完整路径。