假设在我公司，我们有相同的用C ++编写的应用程序，在RHEL5,6和7的机器上运行。
我想从一个构建服务器（运行RHEL7）构建，以获取在旧版RHEL中运行的可执行文件。我可以知道它是否可以实现吗？
我希望如果我在RHEL7中构建，并在RHEL5中提供相应版本的gcc和glibc（以及其他库），则生成的可执行文件应该在RHEL5中运行。我的理解是否正确？还是有更多值得关注的事情？
答案 0 :(得分：2)
我希望如果我在RHEL7中构建，并且RHEL5中提供了相应版本的gcc和glibc（以及其他库），则生成的可执行文件应该在RHEL5中运行。
理论上，是的。实际上，在RHEL7系统上安装多个版本的glibc和其他库可能是一个失败的原因 - 特别是RHEL5需要的旧版本，特别是glibc，它希望对系统有很多了解。
相反可能更容易 - 在RHEL5上构建所有内容，静态链接所有你可以但glibc （它基本上不可能静态链接到glibc）并希望前向二进制兼容性保持足够好。这是通常采用的路径（“建立在你想要支持的最老的Linux发行版上”），但我怀疑glibc的前向二进制兼容性是否有效，因为与RHEL7相比，RHEL5 非常古老
回到最初的计划，在RHEL7机器内的容器中安装RHEL5和6并构建这些版本可能更容易。毕竟，这有点像在RHEL7机器上安装他们的gcc和库版本，但在极其分离良好的sysroots中 - 但没有使用不同构建机器的开销（它们都是同一内核的客户端） ）。
最后，极端的方法是使用另一种libc（仅取决于内核，选择你想要支持的最旧的libc）并静态编译所有内容。这可以通过例如完成。与musl，但你必须编译你的编译器，你的libc和所有依赖项。不过，最好的结果是，您将能够构建完全独立的可执行文件，能够在您确定的最低要求之后在几乎任何内核上运行。
答案 1 :(得分：0)
红帽开发者工具集（DTS）是一个GCC产品，您可以在一个主要的操作系统版本上进行编译，并在该版本和下一个主要版本上进行部署。这将涵盖您的RHEL 6和7工作。对于RHEL 5，您将继续单独执行此操作。
DTS安装新版本的GCC＆＃34;沿着＆＃34;原始/基础版本，因此它不会破坏您的操作系统。
我也喜欢Matteo的容器创意。
请参阅https://developers.redhat.com/products/developertoolset/overview/