作为一名平台和构建工程师，我在一家主要使用 Red Hat Enterprise 及其类似产品的公司中工作，因此我很少使用 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 语言运行时的系统库，对于不在系统库中的函数，将所需代码静态链接到正在链接的共享库（或可执行文件）中。这听起来很可怕，但效果非常好。这可能是因为 Red Hat 是 GCC 的主要贡献者，并确保它保持正常工作。
Ubuntu 有类似的东西吗？我希望有一个 Red Hat 的替代品，以防他们利用 GPL 漏洞成功消灭他们的操作系统的同类产品，因为在每台测试机器上运行他们的操作系统太昂贵了。
我目前对 Ubuntu 编译和运行时的了解已在对相关问题的回答中进行了解释这里。
对于 C++20 的情况，迁移到 Ubuntu LTS 22.04 将满足需求。但是，C++23 已经开始出现。我们可以很快期待 Ubuntu LTS 24.04，但对于将于 2024 年 4 月或 5 月发布的 GCC 14 中的 C++23 支持来说，现在可能还为时过早。我假设“企业”Ubuntu 客户只会在他们的主服务器上安装 LTS 版本，而不是中间版本。
如果 Ubuntu 不这样做，那也没关系。考虑到它是企业 Linux，我想我可能错过了一些东西。
答案1
我不知道 Ubuntu 中是否存在与您描述的“填充库”类似的东西 - 并且不可否认的是，它们是一个优雅的问题解决方案。但是，我认为这个问题在 Ubuntu 中并不那么突出。
Ubuntu 版本通常包括（并内置有，请参阅工具链 PPA及相关维基页面）最新的上游 GCC 版本。
例如，22.04 LTS 有 GCC 11.2，这是当时最新的 FSF 版本，而 Ubuntu 23.10 有 GCC 13.2，这是 FSF 的当前版本（23 年 7 月）。Ubuntu 每六个月发布一次版本，实际上您将始终使用最新的 GCC。
（甚至还有gcc-snapsnot包含最新上游开发版本 GCC 的软件包，但这并不适用于可分发的版本。）
那么，这个问题只会出现在使用 20.04 LTS（最老的受支持 Ubuntu 版本）的开发人员身上，他们需要比 GCC 9.3 更新的编译器。除了升级到 22.04 LTS 或 23.10 并免费获得最新的 GCC 之外，我想不出解决这个问题的更简单的方法了。
此外，如果他们需要最新 GCC 的功能（并且以 Ubuntu 为目标），那么这几乎肯定是为了构建下一个版本的软件。他们为什么要从 20.04 LTS 开始这样做？
而如果这是对受支持版本（目前为 20.04、22.04 和 23.10）上的软件进行维护，那么就不太可能需要对 GCC 进行重大升级。但对于拥有扩展维护 (ESM) 计划的 Canonical 来说，这可能是一个更大的问题。
答案2
是的。前往https://gnu.org，下载 GCC 源代码和构建环境，安装软件包。阅读随附的build-essential所有文件和其他文档。阅读以了解将其放在哪里（可能是树）并在运行时指定它README*man hier/usr/local./configure