我不太使用 Ubuntu，作为一个主要是红帽企业及其类似组织的组织中的平台和构建工程师。
仅仅构建和使用最新的 GCC 的问题是语言运行时库。我要么必须分发它们，使运输复杂化并使律师对 GPL 感到紧张，要么要求我的客户构建和安装相同的 GCC。
我生产闭源商业软件，主要是数学建模，从 C 和 C++ 源代码编译并作为共享库提供。这意味着我对实现跨发行版二进制兼容性非常感兴趣。这是实用的，因为我的库所需的一切都可以从 glibc 和 GCC 语言运行时（libgcc_s.so.1和libstdc++.so.6）获得。这两组库都具有非常强的向前兼容性，因为它们的所有符号都经过版本控制，并且每次行为发生变化时都会创建新版本。
目前，我在 RHEL 8.x 上进行构建。它有相当旧的 GCC (8.x) 和 glibc (2.28)，所以如果我天真地使用它构建我的库，我将向前兼容具有这些库的相同或更高版本的 Linux。然而，旧的 GCC 无法处理开发人员非常想要使用的 C++20 语言标准，更不用说新的 C++23 标准了。RHEL 为此提供了解决方案，但我还没有找到 Ubuntu 的类似解决方案。
Red Hat 解决方案是一个“GCC 工具集”。这些方法有很多，但它们的工作方式都是相同的。他们提供了 GCC 的更高版本（构建为在 RHEL 8.x 的运行时上运行）、标准头文件以及一些 GNU 的特殊脚本ld。这些脚本告诉链接器尽可能使用 GCC 语言运行时的系统库，对于系统库中没有的函数，将所需的代码静态链接到所链接的共享库（或可执行文件）中。这听起来很可怕，但效果非常好。这可能是因为红帽是 GCC 的主要贡献者并确保它保持正常运行。
Ubuntu有类似的东西吗？我希望有一个 Red Hat 的替代品，以防他们利用 GPL 漏洞成功地消除了他们操作系统的类似工作，因为在每台测试机器上运行它的成本太高。
我目前对 Ubuntu 编译和运行时的了解在我对相关问题的回答中进行了解释。
对于 C++20 情况，迁移到 Ubuntu LTS 22.04 就可以满足需求。然而，C++23 开始出现。我们预计 Ubuntu LTS 24.04 很快就会发布，但对于 GCC 14 中的 C++23 支持来说可能还为时过早，GCC 14 将于 2024 年 4 月或 5 月发布。我假设“企业”Ubuntu 客户会仅在其主服务器上安装 LTS 版本，而不是中间版本。
如果 Ubuntu 不这样做，也没关系。鉴于它是企业 Linux，我想我可能会遗漏一些东西。