我读了一些关于使用LD_LIBRARY_PATH的问题的文章，甚至作为包装脚本的一部分：
http://linuxmafia.com/faq/Admin/ld-lib-path.html
http://blogs.oracle.com/ali/entry/avoiding_ld_library_path_the
在这种情况下 - 推荐的替代方案是什么？
感谢。
答案 0 :(得分：11)
您可以尝试添加：
-Wl,-rpath,path/to/lib
到链接器选项。这样可以省去担心LD_LIBRARY_PATH环境变量，并且可以在编译时决定指向特定的库。
对于相对于二进制文件的路径，可以使用$ ORIGIN，例如
-Wl,-rpath,'$ORIGIN/../lib'
（当使用ld静态链接到共享库时，$ ORIGIN可能无效，使用-Wl， - allow-shlib-undefined来修复此问题）
答案 1 :(得分：6)
我总是设置LD_LIBRARY_PATH，我从来没有遇到过问题。
引用第一个链接：
我什么时候应该设置LD_LIBRARY_PATH？简短的回答永远不会。为什么？ 有些用户似乎设置了这个环境变量，因为来自其他用户的错误建议或者他们不知道如何修复的链接错误。
那是 NOT 我称之为确定性问题陈述。事实上，它让人想起I don't like it。 [YouTube，但SFW]。
第二篇博客文章（http://blogs.oracle.com/ali/entry/avoiding_ld_library_path_the）对于问题的本质更为明确......简而言之，图书馆版本冲突ThisProgram需要Foo1.2，但ThatProgram需要Foo1。 3，因此你不能运行这两个程序（很容易）。请注意，大多数这些问题都被一个简单的包装器脚本所抵消，该脚本只为执行的shell设置LD_LIBRARY_PATH，这几乎总是一个交互式shell的子进程。
另请注意，在帖子中很好地解释了替代方案。
我很困惑为什么你会发布一个问题，其中包含明显回答你问题的文章的链接......你是否有一个特定的问题在这两篇文章中没有涵盖（显然足够）？ / p>
答案 2 :(得分：6)
答案在你引用的第一篇文章中。
在UNIX中，可以使用编译器的-L dir选项指定库的位置。 .... 作为使用-L和-R选项的替代方法，可以在编译代码之前设置环境变量LD_RUN_PATH。
答案 3 :(得分：1)
我发现现有的答案确实以一种简单的方式回答了问题：
LD_RUN_PATH（请参阅ld）。仅当命令行中没有-rpath ...时才使用它（gcc命令行上为-Wl,rpath ...）。该变量中定义的路径将添加到ELF二进制文件中的RPATH条目中。 （你可以看到使用objdump -x binary-filename的RPATH - 在大多数情况下它不存在！它出现在我的开发二进制文件中，但是一旦安装了最终版本RPATH就被删除了。）
LD_LIBRARY_PATH）需要搜索库的目录，则在运行时使用 ldd。指定错误的路径可能导致加载错误的库。除了二进制文件中定义的RPATH值之外，还使用此选项（如1）。
LD_RUN_PATH确实不会导致任何安全威胁。当我使用CMake构建我的软件时，-rpath一直在使用。这样我就不必安装所有东西来运行我的软件。 ldd可以自动查找所有.so文件。 （自动化环境也应该这样做，但相比之下它并不是很好。）
LD_LIBRARY_PATH是一个运行时变量，因此你必须小心它。话虽如此，如果我们没有这个特殊功能，很多共享对象将很难处理。是否是安全威胁，可能不是。如果黑客占用了您的计算机，那么无论如何都可以访问该{0}。可能发生的是你在该变量中使用了错误的路径，你的二进制文件可能无法加载，但如果它加载，你可能最终会遇到崩溃的二进制文件或至少一个不能正常工作的二进制文件。一个问题是，随着时间的推移，您将获得新版本的库，并且您可能忘记删除LD_LIBRARY_PATH，这意味着您可能正在使用不安全的库版本。
安全性的另一个可能性是，如果黑客安装了与二进制文件搜索名称相同的虚假库，包含所有相同功能的库，但其中一些功能被欺骗性代码替换。他可以通过更改LD_LIBRARY_PATH变量来加载该库。然后它最终会被黑客执行。同样，如果黑客可以将这样的库添加到您的系统中，那么他已经进入并且可能首先不需要做任何类似的事情（因为他无论如何都完全控制了您的系统。）因为实际上，如果黑客只能将库放在他的帐户中，他不会做任何事情（除非你的Unix盒子总体上不安全......）如果黑客可以替换你的LD_LIBRARY_PATH库之一，他已经拥有完全访问权限到你的系统。因此不需要/usr/lib/...。