zig 为什么可以成为比 C 更好的编译器？

[jinzhongjia]

这个问题之前在tg群讨论过了，发在这里做个记录

实际上，zig 本身实现了一个 C 的编译器，当然不仅仅如此，zig 还提供了一个比较 magic 的东西—— glibc-abi-tool，这是一个收集每个版本的 glibc 的 .abilist 文件的存储库，还包含一个将它们组合成一个数据集的工具。

所以，zig 本身所谓的 “ships with libc” 并不准确，它的确分发 libc，但它只携带每个版本的符号库，仅依赖这个符号库，zig 就可以实现在没有 libc 的情况下仍然正确地进行动态链接！

由于这种特性，这导致 zig 尽管携带了 40 个 libc，却仍然能保持 45MB（linux-x86-64）左右的大小，作为对比 llvm 分发的 clang 完整的工具链的大小多达好几百 M。

关于更多的细节，你可以参考以下链接：

process_headers tool
Updating libc
hacker news
与 C 交互

[jiacai2050]

zig 本身实现了一个 C 的编译器

你这个是哪里得到的结论，zig cc 目前是依赖 llvm 的功能将 c 代码编译成二进制的。

• https://github.com/ziglang/zig/blob/b004060cf888d0c17c2dbdd3e4a77073d1a3b2ea/src/main.zig#L2256

[jinzhongjia]

zig 那边已经打算把arocc拿进来了，https://github.com/ziglang/zig/tree/master/deps/aro
然后这是Loris Cro在这个问答讨论中说的https://www.youtube.com/watch?v=5_oqWE9otaE

[jinzhongjia]

ziglang/zig#16269
ziglang/zig#16268
包括这几个issue也都在说这个事情

[jiacai2050]

这个还是很早期了，而且目前还只支持 linux 64 位，离正式启用还有不少活，你原文最好说清楚。

libc 这个，大部分都是 dynamic link，肯定是只要 header 文件就够了，只有像 musl 这样支持静态链接的才需要包含源码。