hes*_*bar 3 c compiler-construction winapi glibc
最近，我一直在大量阅读有关glibc函数如何在Linux中包装系统调用的信息。但是，我想知道glibc和GNU C编译器之间的关系。
比方说，例如，我想编写自己的C Standard实现并编写一个名为“ newglibc”的新库，而我只需稍作更改即可。例如，在系统调用之前和之后，我都会进行更多检查和采取措施。我需要编写一个新的编译器吗？还是可以使用相同的GNU gcc编译器？
如果编译器与库完全分开，那么有人能够理论上在Windows系统上使用gcc，如果他们可以将其转换为.exe并提供Windows提供的标准C库呢？
谢谢
Linux内核，GNU C库（“ glibc”）和GNU编译器集合（gcc）是三个独立的开发项目。它们通常一起使用，但不一定必须使用。名称中带有“ GNU”的人正式是GNU项目的一部分；Linux不是。
C标准没有在“编译器”和“库”之间进行区分；这是委员会的全部“执行”。GCC是独立于glibc的开发项目，但这是一个有动机的项目，这在很大程度上是历史性的事故：过去，每个商业Unix变体都附带有自己的C库和编译器，而且非常糟糕，按体积计90％的错误是典型。GNU开始为编译器（以及同样很糟糕的shell实用程序）提供了一个不太可怕的替代产品。
在传统的商用Unix上替换编译器比替换C库要容易得多，因为C库不仅仅是C标准第7节中定义的函数；正如您所注意到的，它还提供了内核的最低级别的接口，而且通常没有很好的文档记录。glibc一次至少支持了许多此类Unix，但是如今它只能与Linux和称为Hurd的实验内核一起使用。相比之下，GCC支持许多不同的CPU和内核，而Linux支持许多不同的CPU。
如果您编写自己的C库和/或内核，则编写“后端”相对容易，以便GCC可以作为它们的交叉编译器为其生成代码，而移植GCC 在该环境中运行则要困难一些。您可能还需要为汇编器和链接器编写一个后端，这是第四个项目（“ GNU Binutils”）。将glibc移植到运行Linux的新CPU是一项艰巨而直接的任务。很难将glibc移植到新的操作系统上，尤其是在该操作系统不是Unix-ish的情况下。（Windows 绝对不是Unix风格的，以至于当Microsoft想要简化在Windows下运行为Unix编写的程序时，。我没有化妆。）
如果编写自己的C编译器，则必须使其符合生成代码的库和内核的期望。不幸的是，很多关于“ ABI”规范的文档都针对您所使用的环境，但并非全部。
如果不清楚，请告知我们尚不清楚的地方。