c - 是否可以构建一个与所使用的操作系统和编译器无关的 C 标准库？

Question

首先，我知道任何这样的库都需要至少有一些接口来与系统调用或板支持包或其他任何东西进行交互（例如；对 OS/BSPnewlib有一个有限且定义明确的接口，它不假设对操作系统的亲密访问）。我还可以看到哪里需要类似的东西来与编译器交互（例如，一些东西的细节被标准保留为“实现定义”）。

然而，我研究过的大多数库最终都更倾向于操作系统和编译器。操作系统假设似乎假设可以从特定操作系统环境中访问他们想要的任何部分，并且编译器交互实际上与编译器实现本身相勾结。

因此，基本问题最终是：

1. 是否有可能（并且实际）实现一个完整的 C 标准库，它只有一组非常有限且定义明确的先决条件和/或接口，可以由任何编译器构建并在任何操作系统上运行？
2. 是否存在这样的实现？（我不是要求推荐一个使用，我想我会对可以自己评估的例子感兴趣。）
3. 如果以上任何一个答案为“否”；那么为什么？是什么从根本上使它成为不可能或不切实际的？或者为什么没有人打扰？

---

背景：

我正在做的是将我带到这个兔子洞的尝试是尝试制作一个完全版本化、完全密封的构建链。目标是我应该能够构建一个不依赖于本地环境的项目（除了访问需要的源代码控制仓库并说“有效的 posix shell”或“语言不可知论构建工具的选择是安装并运行”）。鉴于这些依赖关系，构建应该使用相同的编译器和库执行完全相同的操作，而不管安装或未安装哪些编译器和库的版本。通用、可重复、字节相同的输出是我想要移动的目标。

使选择的编译器从 repo 运行并不太难，但我还没有找到一个“开箱即用”的 C 标准库。他们似乎都假设他们和编译器（例如__gnuc_va_list）之间存在一些神奇的无证接口，或者充其量想要对托管环境进行某种配置探测，这对于我的目标来说是无用和适得其反的。

这看起来是一个无底洞的兔子洞，如果不首先尝试找到替代方案，我就不愿意开始。

标签： ccompiler-constructionstandardscompatibilitylibc