self-host building musl, glibc, and mingw-w64 #4313
Labels
contributor friendly
This issue is limited in scope and/or knowledge of Zig internals.
enhancement
Solving this issue will likely involve adding new logic or components to the codebase.
frontend
Tokenization, parsing, AstGen, Sema, and Liveness.
stage1
The process of building from source via WebAssembly and the C backend.
Milestone
Once we have the "cache hash" API self-hosted (See #4311), another big win is self-hosting the code that builds zig's libcs from source, for the target platform.
This provides several benefits:
There will only be one implementation, across stage1 and self-hosted, rather than two. Less room for bugs. Improving and maintaining the self-hosted version will be work that benefits both stage1 and self-hosted.
zig translate-c
is already self-hosted. Once building libc is also self-hosted, creating the clang command line can be moved (at least partially) to self-hosted as well. Combined with making linking self-hosted (see self-host linking #4314), this will make it possible to self-host the drop-in C compiler feature (see use case: ability to use zig as a drop-in replacement for a C compiler #3089).multi threading. The C++ stage1 compiler is single-threaded. However, the Zig Standard Library and self-hosted compiler is designed to take advantage of multiple CPUs & cores. With building of libc self-hosted, it's a straightforward path to make compilation of C objects multi-threaded, taking full advantage of hardware resources.
The text was updated successfully, but these errors were encountered: