我是用 C++ 编写的旧代码库的新维护者，目标是 C++0x 标准，代码中包含多个 gcc 和 g++ 依赖项。我担心 CentOS 7 EOL 后是否要修补该程序的依赖项。当然，还有 4 年的时间，但最好还是做好计划……
该代码库的许多问题之一是它取决于GNU Pth。自 2006 年以来，该库的上游就不再维护，现在新软件应该使用 Boost 协程或类似的东西来实现等效的行为，或者只使用 pthreads。
我 100% 确信我们对 Pth 的使用，或者 Pth 本身，取决于版本 2.17（在 CentOS 7 上，工作正常）和 2.27（在 Ubuntu 18.04 上，破坏了 glibc）中引入的错误或不兼容的更改。我们的软件）。即使使用完整的源代码和调试符号，这个问题对于调试来说也是极其有害的，因为 Pth 的操作模型不断地破坏堆栈，使得很难判断程序如何进入特定的故障模式。
我已将问题隔离到 glibc 版本，并在使用 glibc 2.28 的 CentOS 8 上进行了尝试。对我来说，这似乎不是一种回归，而是一种故意的改变，尽管它破坏了向后兼容性。
最近观察到的 glibc 崩溃并不是我在这里要关注的重点。我想知道是否有任何存储库的 EOL 日期比 CentOS 7 更长，并且计划在 CentOS 8 或 Ubuntu 20.04 上支持 glibc 2.17。
当然，我可以编译 glibc 2.17 并将其静态链接到二进制文件中，但这意味着我不再收到该版本 glibc 的安全更新。由于该软件直接侦听可从公共互联网访问的端口，因此我根本不喜欢这个想法。
我可能最终会通过 git 平分来找到导致损坏的 glibc 的确切版本，但即便如此，负担仍然会存在我的维护我选择的 glibc 版本的安全补丁。我喜欢企业发行版的原因之一是，您可以获得多年的完全 ABI 和 API 兼容的安全更新，因此您可以在方便的时候慢慢地解决应用程序软件向前移植问题。这可能看起来很疯狂，但我想将这个时间表延长到 2024 年 6 月之后（CentOS 7 安全更新结束）。
如果我要继续使用旧的但已打补丁的 glibc 版本，我有哪些选择？或者，在没有任何好的选择的情况下，我是否最好利用现在到 2024 年 6 月的时间来解决根本问题，以便可以进行升级？