| ▲ | mananaysiempre 3 days ago |
| > In exchange [for eliminating the dependency on LLVM], Zig gains these benefits: > All our bugs are belong to us. > The compiler becomes trivial to build from source and to bootstrap with only a C compiler on the host system. > We stop dealing with annoying problems introduced by Linux distributions and package managers such as Homebrew related to LLVM, Clang, and LLD. There have been and continue to be many. > The Zig compiler binary goes from about 150 MiB to 5 MiB. > Compilation speed is increased by orders of magnitude. > [...] https://github.com/ziglang/zig/issues/16270 |
|
| ▲ | donio 2 days ago | parent | next [-] |
| The Go toolchain is a nice illustration of this approach working in practice. It fully bootstraps in 90 seconds on my aging laptop and since it's fully self-hosted it doesn't even need a C compiler unless you want cgo support. LLVM takes 2 hours to build on the same host and zig (with the LLVM backend) is another 20 minutes. It will be awesome if that can be brought down to 2 minutes or less. |
| |
| ▲ | AndyKelley 2 days ago | parent | next [-] | | Is that building Go with Go? Or actual bootstrapping? Check this out... Building Zig with Zig: andy@bark ~/s/zig (master)> time zig build
________________________________________________________
Executed in 11.67 secs fish external
Bootstrapping with only a C compiler dependency (not even make or shell!): andy@bark ~/s/zig (master)> time cc -o bootstrap bootstrap.c; and time ./bootstrap
________________________________________________________
Executed in 55.10 millis fish external
gcc -o zig-wasm2c stage1/wasm2c.c -O2 -std=c99
./zig-wasm2c stage1/zig1.wasm zig1.c
gcc -o zig1 zig1.c stage1/wasi.c -std=c99 -Os -lm
./zig1 lib build-exe -ofmt=c -lc -OReleaseSmall --name zig2 -femit-bin=zig2.c -target x86_64-linux --dep build_options --dep aro -Mroot=src/main.zig -Mbuild_options=config.zig -Maro=lib/compiler/aro/aro.zig
./zig1 lib build-obj -ofmt=c -OReleaseSmall --name compiler_rt -femit-bin=compiler_rt.c -target x86_64-linux -Mroot=lib/compiler_rt.zig
gcc -o zig2 zig2.c compiler_rt.c -std=c99 -O2 -fno-stack-protector -Istage1 -Wl,-z,stack-size=0x10000000 -pthread
________________________________________________________
Executed in 305.06 secs fish external
| | |
| ▲ | donio 2 days ago | parent [-] | | > Is that building Go with Go? Or actual bootstrapping? Normally it's just Go with Go. Besides the Go compiler you need bash if you want to use the normal bootstrap script but not much else. You can build your way up from C by building an old enough version of Go that was still C based but that's not usually done these days. > Executed in 11.67 secs Nice! |
| |
| ▲ | cxr 2 days ago | parent | prev [-] | | Sometime after Minix 3 but before it had attained the critical mass for a self-sustaining community, compilation times went from 10 minutes on low-end hardware to ~3 hours, and the answer to the question "Why?" was "LLVM/clang". |
|
|
| ▲ | wiz21c 2 days ago | parent | prev | next [-] |
| maybe I'm wrong, but rust is still using LLVM. When I see that list of benefits, I wonder why rust is still on LLVM... (honest question, I use rust everyday and I'm happy with it, except for compilation times :-) ) |
| |
| ▲ | zozbot234 2 days ago | parent | next [-] | | Rust has cranelift as a natively bootstrapped alternative these days. No different from Golang or Zig. | | |
| ▲ | MuffinFlavored a day ago | parent [-] | | When will it become the default? What does it say about LLVM project that everybody starts off on it and then gets off of it? |
| |
| ▲ | rowanG077 2 days ago | parent | prev [-] | | Rust depends heavily on the llvm optimization pipeline afaik. So it would be a heavy investment to write native backends. |
|
|
| ▲ | remindmeagain 3 days ago | parent | prev [-] |
| Does this mean `zig c++` is going away with LLVM dropped? That would be a shame - so useful. |
| |
| ▲ | flohofwoe 2 days ago | parent | next [-] | | AFAIK the current plan for zig cc is outlined here: https://github.com/ziglang/zig/issues/20875 E.g. LLVM will still be around one way or another, just not as deeply integrated as it is now. | |
| ▲ | forrestthewoods 3 days ago | parent | prev [-] | | As long as Zig builds the glibc shim libraries those can be used in a separate Clang build system. It’d be nice if Zig added a command to emit them more explicitly to use in non-Zig build systems. Would be awesome actually. Plz? | | |
| ▲ | remindmeagain 3 days ago | parent [-] | | I'm trying to wrap my mind around what you wrote. Do you envision a different binary separate from zig? The closest thing I could find online is: https://stackoverflow.com/questions/78892396/how-to-link-to-... | | |
| ▲ | forrestthewoods 3 days ago | parent [-] | | Cross-compiling is super super easy conceptually. All you need is headers and an import library. Windows is trivial to cross compile for because there is a single set of headers. And for DLLs Windows compiler like to generate an import lib. Which is basically a stub function for all exports. Linux is stupid and sucks. Linux doesn’t have a single set of headers because programmers in the 80s didn’t know better. And Linux linking to a shared library expects you to have a full copy of the library you expect to exist at runtime. Which is fucking stupid and ass backwards. But I digress. So. Why is Zig awesome for crosscompiling C++? Because Zig fixed Linux sucking ass. Zig moves mountains to generate thin “import libs” of the half dozen .so files you need to link against to run on Linux. If you want to cross compile C++ for Linux all you need is clang++ executable, headers, and those stub .so files. Zig generates the libs implicitly as part of its zig cc build process. I’m asking for the half dozen (C) or dozen (C++) libs to be explicitly exportable by Zig. So that they can be trivially used in other build systems. I’ve got a custom polyglot build system that leverages Zig. But I have to zig cc a hello_world.cpp and parse the output to get the paths to those libs. Which is annoying and janky. Hopefully that helps? | | |
| ▲ | TUSF 2 days ago | parent | next [-] | | > Linux is stupid and sucks. None of this is Linux's fault. I'd argue this is both C's and GNU's fault. The need for a copy of the library, seems to be just a tooling convention. GCC's linker requires it, so others do the same thing. The executable itself doesn't need to know where a given symbol is in a shared library's memory at runtime (or even what shared library a symbol comes from, just that it's inside one of the libraries declared as needed in its dynamic section), because that's the (runtime) linker's job to figure out. Regardless, you don't actually need a full copy of the library—a stub will suffice. I don't know a ton about compilers, but as far as I know, there's no reason clang's linker (LLD) couldn't just not require an existing copy of the shared library you're linking to. Can't do anything about requiring a version of the libc headers you need for every platform though. | | |
| ▲ | forrestthewoods 2 days ago | parent [-] | | You’re totally wrong. Linux doesn’t suck. Merely all the tools you are required to use on Linux suck. Which for all intents and purposes means Linux sucks. IMHO. | | |
| |
| ▲ | rstat1 2 days ago | parent | prev | next [-] | | >> Linux doesn’t have a single set of headers because programmers in the 80s didn’t know better. I would argue that it does, but because its apparently illegal (obvious exaggeration alert) to package all the parts of a single entity together in one package, it just seems like it doesn't, where as on Windows there's a single package (the Windows SDK) that contains the majority of the relevant stuff. I do however 100% agree with you on linking to shared libraries. The way Linux compilers handle that is fucking stupid. | | | |
| ▲ | remindmeagain 3 days ago | parent | prev [-] | | Yes it does. Thank you. |
|
|
|
|
