避免过于具体的依赖答案

【问题标题】：Avoiding too specific dependencies避免过于具体的依赖
【发布时间】：2014-06-08 20:34:29
【问题描述】：

我在 Linux 上使用以二进制形式分发的共享 C 库。问题是依赖项被设置为需要开发机器上可用的版本。例如，每个版本都需要（当时）最新的 glibc，并且只需要其系统上准确版本的 libreadline。

我已经联系了开发人员，他们不知道该怎么做。据我所知，他们并没有有意识地使用最新的特性，所以库应该继续使用旧的依赖项。我认为他们在 Linux 上使用 gcc，但他们也使用复杂的 make 系统来控制其他编译器为 Windows 和 Unix 构建。

您可以如何以及在多大程度上管理构建过程，以便库只需要足够版本的依赖项并接受更高版本？

This 是一个相关问题。

编辑： 明确地说，我想知道如何构建程序，以便它们接受具有特定版本号或更高版本号的依赖项。无论是开发人员编译还是我编译，我都希望能够分发一个不需要构建环境中存在的依赖版本的二进制文件。

编辑 2： 改写问题后，我意识到这个问题之前已经讨论过很多次了。一些最佳问答：

Deploying Yesod to Heroku, can't build statically

Compile with older libc

Linking against an old version of libc

How can I link to a specific glibc version?

【问题讨论】：

这就是为什么我更喜欢使用免费开源软件的原因。您依赖生产者的善意来为您的系统构建软件。
它们是 rpm/apt “依赖”还是库代码调用 libreadline 本身？
@Basile：哎呀，抱歉暗示源不可用。不过，这个库非常大，而且很难构建。
@Rob11311：库正在调用特定版本。
如果库有可用的源代码，那么为其构建服务项目应该是一个更好的解决方案，因为它将为大量系统生成本机包。如果是运行时调用，那么它们应该链接到较旧的操作系统版本，因为假定较新的库版本兼容。

标签： c linux build dependencies shared-libraries

【解决方案1】：

这不是很鼓舞人心的信心。他们应该建立在一个稳定的基线版本上，它可能只是一个虚拟安装。某些版本的 Linux 复制构建环境，因此包不会链接到更新的库版本。

openSUSE 构建服务，让开发者可以构建二进制包，用于各种http://openbuildservice.org/about/

IIRC readline 是一个 GPL 程序，在 http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html#Availability 检查表明它是 GPL v 3，因此如果他们使用 libreadline 函数并且应该为您提供其库的源代码，它们可能违反了 GPL。我不确定您是指 rpm/apt 包依赖项，还是它们的库实际上正在调用 libreadline。

如有必要，您始终可以从 rpm 或 apt 包中提取文件，以避免因打包不当而导致的软件管理器问题。

【讨论】：

你的主要观点有点被掩埋了，基本的解决方案是建立在你想要支持的最古老的系统上，并依赖于与较新的库版本的兼容性。