假设在我的公司，我们有相同的应用程序用 C++ 编写，运行在 RHEL5、6 和 7 的机器上。
我想从一个单独的构建服务器（运行 RHEL7）构建，以获得在旧版本 RHEL 中运行的可执行文件。请问可以实现吗？
我希望如果我在 RHEL7 中构建，并且在 RHEL5 中具有相应版本的 gcc 和 glibc（以及其他库），则生成的可执行文件应该在 RHEL5 中运行。我的理解正确吗？还是有更多需要注意的地方？
【问题讨论】：
我希望如果我在 RHEL7 中构建，并且在 RHEL5 中具有相应版本的 gcc 和 glibc（以及其他库），则生成的可执行文件应该在 RHEL5 中运行。
理论上，是的。实际上，在您的 RHEL7 系统上安装多个版本的 glibc 和其他库可能是一个失败的原因 - 尤其是 RHEL5 所需的非常旧的库，尤其是 glibc，它期望对系统有很多了解。
反过来可能更容易——在 RHEL5 上构建所有东西，尽可能静态链接但 glibc（基本上不可能静态链接到 glibc）并希望前向二进制兼容性足够好。这是通常采用的路线（“在您想要支持的最古老的 Linux 发行版上构建”），但我怀疑 glibc 的前向二进制兼容性是否可行，因为 RHEL5 与 RHEL7 相比非常古老.
回到最初的计划，在 RHEL7 机器内的容器中安装 RHEL5 和 6 并构建这些版本可能更容易。毕竟，这有点像在 RHEL7 机器上安装他们的 gcc 和库版本，但在 非常 完全分离的 sysroot 中 - 但没有使用不同构建机器的开销（它们都是相同内核的客户端)。
最后，极端的方法是使用替代 libc（仅取决于内核，选择您想要支持的最旧的）并静态编译所有内容。这可以做到，例如使用 musl，但您必须编译您的编译器、您的 libc 和所有依赖项。尽管如此，好的结果是您将能够构建完全独立的可执行文件，能够在您确定的最低要求之后几乎在任何内核上运行。
【讨论】：
Red Hat Developer Toolset (DTS) 是一种 GCC 产品，您可以在其中在一个主要操作系统版本上进行编译，然后在该版本和下一个主要版本上进行部署。这将涵盖您的 RHEL 6 和 7 工作。对于 RHEL 5，您将继续单独执行此操作。
DTS 将新版本的 GCC “与”原始/基本版本一起安装，因此它不会破坏您的操作系统。
我也喜欢 Matteo 的容器创意。
见https://developers.redhat.com/products/developertoolset/overview/
【讨论】：