如何用旧的stdlib和libc在旧的linux发行版中构建C++17应用程序？

Question

我需要使用包含C++17 6.0.22 (GLIBCXX 3.4.22)和libc 2.24的发行版构建一个libstdc++应用程序。这些版本的库不允许我构建现代的c++，也不能更新系统的版本。事实上，我需要一个正确的工作应用程序(可能是从源代码中携带编译的stdlib )，这样我就可以提供给我的客户，他们也会使用它。发行版的repos中有llvm-9，这提供了一个我可以使用的标准库。

我试了两件事：

1. 用于构建基于libc++的应用程序，但这将迫使我也重新编译系统依赖项，并将它们与包一起分发(但我甚至不知道如何做到这一点)，
2. 从源代码构建libstdc++，并与包

一起分发。

(1)方法需要花费太多的时间来编译，我需要知道如何重新编译系统依赖项并分发它们。它不是一个小hello world应用程序，它使用了大量的系统dep。

我刚刚尝试的(2)方法由于许多错误(类型未知、未预料到的标识符等)而失败。

Answer 1

libstdc++是C++编译器(gcc或llvm)的一部分。您不仅需要当前的libstdc++，还需要与其配套的编译器。每个编译器的当前版本(这是支持C++17所需的)要求与其一起编译的程序的libstdc++的当前版本。我还没有重复检查binutils依赖项，但是新的编译器可能需要更新版本的binutils (特别是ld链接器)。新C++标准的高级特性可能需要在系统链接器中实现新功能。更不用说新的编译器功能了(例如，gcc的curren版本中的链接时间优化需要链接器、ld或gold的紧密关联支持，它实际上将在链接阶段再次调用编译器)。

您唯一的实际解决方案是引导辅助工具链，从binutils开始，最后使用当前版本的编译器。您不必更新或替换系统安装的libstdc++、编译器或ld。通过运行它们各自的配置脚本，就可以将整个工具链安装在一个单独的目录层次结构中，这样它们就不会干扰您的系统安装的二进制程序和编译器。

至于其他系统依赖项，您可能只需要重建C++依赖项。作为C库的系统依赖项不太可能需要重新构建。尽管如此，如果你有一些，你将不得不重建他们，这就是它的方式，没有替代的捷径。

差不多就是这样。没有其他选择。正如您可以推测的那样，引导整个工具链以“侧面加载”到具有现有编译器工具链的系统上，以不干扰它的方式，是一项不小的努力。这对技术熟练、经验丰富的开发人员或系统管理员来说也是一个挑战。但这当然是可行的，我几年前就做过了，在以前的工作中。这样做是有可能的，所以我看不出为什么现在不可能这样做；这几乎是唯一可行的方法，可以在发行版上支持C++的现代版本，该发行版附带了一个旧的编译器收费链(不支持当前的C++标准)。