未找到共享库答案

【问题标题】：Shared Libraries Not Found未找到共享库
【发布时间】：2014-08-12 11:14:34
【问题描述】：

我有一个使用多个共享库的程序。我可以在用于编译程序的机器上很好地编译和运行程序。当我尝试将可执行文件复制到另一台机器并在通过 apt-get 安装所需的包后运行它时，我收到以下错误：

“加载共享库时出错：libconfig++.so.8: 无法打开共享对象文件：没有这样的文件或目录”

运行$ locate libconfig++.so 后，我了解到我在当前系统上安装了 libconfig++.so.9，而不是 libconfig.so.8。

然后我手动将所有共享库与可执行文件一起复制到新系统，然后程序运行良好。我不认为这将是一个长期的解决方案，因为这些库不会像通常那样收到补丁和更新，从而产生潜在的安全风险。

有什么方法可以编译我的程序，使其依赖于 libconfig++.so 而不是 libconfig++.so.x，或者有什么方法可以让我手动包含特定的共享库，同时仍然可以更新它们?

我还考虑了这样一个事实，即我在分发程序的方式上做的事情完全错误。有没有办法以完全避免这种情况的方式分发我的程序？

【问题讨论】：

大多数 Linux 程序使用源代码重新分发，它们是作为安装过程的一部分进行编译的。你想要的是“linux binary redistribution”——只要在谷歌中输入这个并享受阅读——这是一个复杂的问题。
@Sathish：不不要那样做。版本控制方案的存在是有原因的，绕过它只是愚蠢的，因为您知道版本已更改，因为 ABI 已更改。
@Zachary：在目标机器上构建，或者类似的机器。

【解决方案1】：

当你用 -lsomelibrary 编译你的程序时，编译器会在你的系统中搜索 libsomelibrary.so，它会链接到类似 libsomelibrary.so.x.y 的东西从现在开始，你的软件会被绑定到那个特定的主要版本（名称中的 x）。

这意味着它只适用于 x 系列库。如果发行版发布了具有相同主要版本的较新版本（例如 libsomelibrary.x.z），您的应用程序应该可以正常工作。

但是，您不允许使用该库的另一个主要版本。如果您这样做（通过将主要版本链接到不同版本），正如有人在此处建议的那样，应用程序可能会启动（或可能会在开始时立即崩溃），但您永远无法确定应用程序会按计划工作。

TL'DR：

当您编译时，链接器会查找 libsomelibrary.so，它将链接到特定版本，例如 libsomelibrary.so.x.y。

当您运行您的应用程序时，系统将查找 libsomelibrary.so.x.*（相同的主要版本，任何次要版本）

【讨论】：

【解决方案2】：

回答上一段中的问题：分发二进制文件（特别是依赖于共享对象的二进制文件）的标准方法是使用目标发行版的包管理系统（dpkg、rpm 或两者）。这些包格式将要求系统安装依赖项（在您的情况下为 libconfig++）。如果没有，用户可以使用 apt/yum 自动下载安装。

【讨论】：

【解决方案3】：

验证您的 makefile 是否要求加载版本 9 共享库。

这取决于您的程序调用的函数的用法。

如果您在 8 - 9th 版本的 library 之间调用的函数没有重大变化，则不需要潜在地复制 lib。

当然要创建象征性的喜欢。

如果您认为，您的程序不应该依赖所有这些东西。

去静态库，你可以找到 libconfig.a 存档，你可以链接到你的程序，因此当你运行其他机器时没有依赖关系。

【讨论】：