Skip to content

self-host building musl, glibc, and mingw-w64 #4313

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
andrewrk opened this issue Jan 29, 2020 · 3 comments
Closed

self-host building musl, glibc, and mingw-w64 #4313

andrewrk opened this issue Jan 29, 2020 · 3 comments
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

Comments

@andrewrk
Copy link
Member

andrewrk commented Jan 29, 2020

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.

@andrewrk andrewrk added enhancement Solving this issue will likely involve adding new logic or components to the codebase. contributor friendly This issue is limited in scope and/or knowledge of Zig internals. frontend Tokenization, parsing, AstGen, Sema, and Liveness. stage1 The process of building from source via WebAssembly and the C backend. labels Jan 29, 2020
@andrewrk andrewrk added this to the 0.7.0 milestone Jan 29, 2020
@andrewrk andrewrk modified the milestones: 0.7.0, 0.6.0 Feb 17, 2020
@andrewrk andrewrk modified the milestones: 0.6.0, 0.7.0 Mar 29, 2020
@vedantroy
Copy link

vedantroy commented Jun 17, 2020

@andrewrk
I've been investigating this issue. The question I have is, how much code should be ported from C++ to Zig? For example: the build_musl and build_libcxx call the function codegen_build_and_link.

Should this function also be ported from C++ to Zig? (I don't have good intuition for which functions should stay in C++ and which functions should be ported to Zig).

@andrewrk
Copy link
Member Author

In general, as much code should be moved from C++ to zig as possible. The only limitation is when doing so would introduce a cyclic dependency.

As an example the reason translate-c can be self hosted is that the self hosted compiler does not use the @cImport feature.

Likewise, the zig code that gets compiled into stage1 does not need to be linked into an executable, only an object file or static library.

Hope that helps, happy to discuss more if you have any other questions.

@andrewrk
Copy link
Member Author

Landed in fe117d9.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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.
Projects
None yet
Development

No branches or pull requests

2 participants