c - c编译器和c标准库的关系

Question

我最近阅读了大量有关 glibc 函数如何在 linux 中包装系统调用的资料。不过，我想知道 glibc 和 GNU C 编译器之间的关系。
比方说，我想编写自己的 C 标准实现并编写一个名为“newglibc”的新库，我只是稍微做了一些改动。例如，我在系统调用前后进行了更多检查和操作。我必须编写一个新的编译器吗？或者我可以使用相同的 GNU gcc 编译器吗？

如果编译器与库完全分离，那么从理论上讲，如果有人可以将 gcc 转换为 .exe 并提供 Windows 提供的标准 C 库，那么他们是否能够在 Windows 系统上使用 gcc？
谢谢

Answer 1

Linux 内核、GNU C 库(“glibc”)和 GNU 编译器集合 (gcc) 是三个独立的开发项目。它们经常一起使用，但并非必须如此。名称中带有“GNU”的那些是 GNU 项目的正式组成部分； Linux 不是。

C 标准不区分“编译器”和“库”；这对委员会来说都是一次“实现”。 GCC 是一个独立于 glibc 的开发项目，这在很大程度上是一个历史偶然——但却是一个有动机的项目:在过去，每个商业 Unix 变体都带有自己的 C 库和编译器，它们很糟糕 , 90% 的错误是典型的。 GNU 开始为编译器(以及同样糟糕的 shell 实用程序)提供一个不那么糟糕的替代品。

替换传统商业 Unix 上的编译器比替换 C 库要容易得多，因为 C 库不仅仅是 C 标准第 7 条中定义的函数；正如您所注意到的，它还为内核提供了最低级别的接口(interface)，而且通常没有很好的文档记录。 glibc 曾经至少在某种程度上支持这些 Unix，但现在它只能用于 Linux 和一个名为 Hurd 的实验内核。相比之下，GCC 支持数十种不同的 CPU 和内核，而 Linux 支持数十种不同的 CPU。

如果您编写自己的 C 库和/或内核，那么编写“后端”以便 GCC 可以作为交叉编译器为它们生成代码相对容易，而将 GCC 移植到 在该环境中运行。您可能还需要为汇编器和链接器编写后端，它们是第四个项目(“GNU Binutils”)。将 glibc 移植到运行 Linux 的新 CPU 是一项庞大但直接的任务；将 glibc 移植到新操作系统很难，特别是如果该操作系统不是 Unix-ish。 (Windows 决定 不是 Unix-ish，以至于当微软想让它更容易在 Windows 下运行为 Unix 编写的程序时，阻力最小的路径是 bolt an in-house clone of the Linux kernel onto the side of the NT kernel。我不是弥补这一点。)

如果您编写自己的 C 编译器，则必须使其符合为其生成代码的库和内核的期望。很多内容都记录在您工作环境的“ABI”规范中，但不幸的是，并非全部。

如果还不清楚，请让我们知道还有什么不清楚的地方。