使用可执行文件分发共享对象（最佳实践？）答案

【问题标题】：Distribute Shared Object with Executable (Best Practice?)使用可执行文件分发共享对象（最佳实践？）
【发布时间】：2013-12-20 22:49:26
【问题描述】：

我需要在我的应用程序中分发 OpenSSL 版本。我不能使用 Ubuntu，因为发行版当前禁用了 TLSv1.1 和 TLSv1.2。

我已经阅读了一些关于如何解决丢失共享对象的帖子（例如，How to add shared library search path to a executable file?）。

我担心我有一个与 disto 同名的库，并且它的二进制文件与 distro 兼容。

我的问题是，有没有一种最佳实践可以在预期发生冲突的地方分发共享对象？

【问题讨论】：

标签： c++ c linux shared-libraries ld

【解决方案1】：

将 SO 放在一个私有目录中，并在运行可执行文件之前将该目录添加到包装脚本中的 $LD_LIBRARY_PATH 环境变量中。

【讨论】：

谢谢伊格纳西奥。这有两个问题（对不起，我应该列出它们）。首先，我不希望人们必须使用 LD_LIBRARY_PATH。其次，它以 root 身份运行，因此不支持 LD_LIBRARY_PATH（即使使用 sudo -E）。
@noloader 人们不需要设置 LD_LIBRARY_PATH，你创建一个 shell 脚本，将它与你的可执行文件放在一起，shell 脚本设置 LD_LIBRARY_PATH 并运行可执行文件。人们运行 shell 脚本（例如 sudo）而不是真正的可执行文件。
谢谢，不。是否有任何关于这样做的最佳实践的阅读？我知道运行时链接器存在很多潜在问题（DLL Hell 和 Binary Planting 不仅仅是 Windows 问题）。例如，请参阅Breaking the links: Exploiting the linker。

【解决方案2】：

与在包装脚本中设置 LD_LIBRARY_PATH 环境变量相反，您还可以使用额外的链接器标志编译可执行文件，这些标志添加目录以搜索共享库。

链接器标志是-Wl,-rpath,<path to lib directory>

例如，假设您将应用安装到/opt/myapp/bin，您还可以有一个文件夹/opt/myapp/lib，并在该文件夹中放置您的libssl.so。然后，您将使用额外的链接器标志-Wl,-rpath,/opt/myapp/lib 编译您的应用程序。然后，当您运行您的应用程序时，它会先在该文件夹中查找，然后再在标准文件夹中搜索共享库。

【讨论】：