在 Linux 上分发软件时的库依赖关系？答案

【问题标题】：Library dependencies when distributing software on Linux?在 Linux 上分发软件时的库依赖关系？
【发布时间】：2017-08-18 11:07:22
【问题描述】：

我正在尝试为一个 Qt 软件发布 Linux 版本，但我是一个毫无头绪的 Linux 新手。我已经使用静态链接的 Qt 库构建了我的应用程序，并制作了 .deb 和 .rpm 包，但是当我测试它们时，我收到有关某些发行版上缺少库的警告。例如，我的 .deb 版本在 Debian 和 Ubuntu 上运行良好，但由于缺少库，它无法在 Linux Mint KDE 上启动。运行 ldd 我发现缺少四个库：

libpng16.so.16 => not found
libicui18n.so.57 => not found
libicuuc.so.57 => not found
libicudata.so.57 => not found

显然，我需要以某种方式确保所有必要的库都存在，但是所需的库列表似乎有所不同。例如，Linux Mint Cinnamon 列出了 33 个库，而 Ubuntu Unity 列出了 34 个（libpng12.so.0 是额外的）。我还假设其中一些库是所有发行版都附带的标准 Linux 库，因此我不需要包含它们。

我真的不知道我在做什么，所以有几个问题：

确定需要包含在 .deb 和 .rpm 包中的库列表的最佳方法是什么？如果 ldd 是最佳选择，我是否需要包含所有列出的库，或者是否有一些作为标准与所有 Debian/rpm 发行版捆绑在一起？

包含这些库的最佳方式是什么？你是在包中包含它们还是在依赖列表中指定它们？

任何其他一般性建议将不胜感激，因为我不确定我是否以正确的方式进行。

谢谢。

【问题讨论】：

你是否为你的包添加了正确的依赖项？你真的应该列出你拥有的所有依赖项，即使是那些“标准”或“系统”的包。
不同的 Linux 发行版有不同的库。在 Fedora 上构建的 rpm 不太可能安装在 CentOS 或 RHEL 上，反之亦然。同上 deb。在 Linux 上分发 codez 的唯一实用方法是作为源代码。这就是 Linux 的设计目的：免费软件，作为源代码分发。可以实现的最大目标是在给定 Linux 发行版的旧版本上构建软件，该软件应该可以安装在更高版本上——但只能安装在同一个 Linux 发行版上——因为二进制 ABI 通常是向后兼容的。跨度>
stackoverflow.com/a/33837854/412080
@Someprogrammerdude 我现在已经包含了所有依赖项，但它似乎仍然无法正常工作（下面对 Rodger 的回复中有更多详细信息）。
@SamVarshavchik 非常感谢您关于在旧版本上构建的建议。我在 Debian 9.1 上构建，但切换到 8.4，现在它在 Ubuntu 和 Mint 上运行良好。此外，该应用程序是开源的，但我想为流行的发行版提供二进制文件。

标签： c++ linux

【解决方案1】：

不要考虑库依赖；考虑 package 依赖项。

当您创建 (deb, rpm) 包时，您可以列出它所依赖的其他包。找出哪个包中有您想要的库，然后将该包添加为依赖项。

然后，当用户安装您的包时，如果需要，他们的包管理器还将安装它所依赖的包。 Presto：你有你需要的库。

【讨论】：

谢谢，我找到了 apt-file 程序，它可以告诉您 Debian 上的库所在的软件包。我将所有包都包含在依赖列表中，但是当我在 Linux Mint 上运行时，我仍然遇到依赖问题，即使该库已明确安装。正如 Sam Varshavchik 在上面的评论中所建议的那样，似乎解决方案是建立在旧版本的发行版上。我在 Debian 9.1 上构建，但在更改为 8.4 后，问题似乎得到了解决。这是排序的 .deb 构建，所以我现在就去尝试 .rpm 版本。