Zig Makes Rust Cross-Compilation Just Work(actually.fyi)
actually.fyi
Zig Makes Rust Cross-Compilation Just Work
https://actually.fyi/posts/zig-makes-rust-cross-compilation-just-work/
24 comments
Tried to understand the reason zig is able to compile a c program for a different platform, as opposed to a regular C compiler, but i couldn’t really understand why (since zig is using libclang underneath). Could someone here explain this particular bit ?
Zig bundles its own private copies of glibc or musl for each platofrm, crt.o, system headers, cross-linkers, and clang. They've done a lot of work to replicate cross-build toolkits for each target:
https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
As a Rust user I'm super jealous of that, because Rust's "rustup target add" gives a false illusion of being able to cross-compile, but it can only build object files/static libraries, and if you ask for anything more, Rust just spits a big linker error and you're on your own.
https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
As a Rust user I'm super jealous of that, because Rust's "rustup target add" gives a false illusion of being able to cross-compile, but it can only build object files/static libraries, and if you ask for anything more, Rust just spits a big linker error and you're on your own.
Wonder if Rust should pursue this as a feature as well - might be hard to promise this as a fully fledged feature when Cranelift comes into the picture though. Still it could be possible to ship a linker that can handle cross-compiling like Zig and compile C code with LLVM irregardless of the Rust backend.
Either way, hope Zig and Rust continue to inspire each other a bit!
Either way, hope Zig and Rust continue to inspire each other a bit!
I've only ever cross compiled no_std rust, but as long as I'm writing a rust app with C deps (and not a C app with rust deps) everything has just worked for me.
What caused the linker errors for you?
(My issues with a rust lib for a C app were based around how rustc didn't want to include panicking code from core, even with a panic handler defined)
What caused the linker errors for you?
(My issues with a rust lib for a C app were based around how rustc didn't want to include panicking code from core, even with a panic handler defined)
Rust depends on the operating system already having a cross-linker and sysroot for the target platform. You probably have them already installed.
On a "clean" OS, you get:
• Panics from sys crates using the pkg_config crate, because the target sysroot is missing. It can auto-detect available sysroot on some Linux platforms, but on others you need to fiddle with env vars.
• Screen full of linker errors, because the linker for the host OS doesn't know what to do with the target OS's object files. It's less terrible if you enable a semi-secret option for bundled lld, but it's too buggy to use on some platforms.
Cross-compilation from one Linux flavor to another Linux flavor is reasonably easy with some distros. But anything more adventurous like Mac -> Linux just falls apart and you need to spend a whole day copy-pasting configs and installing bitrotting 3rd party Homebrew formulas from random people on the Internet.
Rust's tooling is usually excellent, but cross-compilation feels half-finished. The Rust's own side of it is fine (cross-compiles object files like a champ, has cross-libstd), but anything not written by the Rust project is left as "not our problem".
On a "clean" OS, you get:
• Panics from sys crates using the pkg_config crate, because the target sysroot is missing. It can auto-detect available sysroot on some Linux platforms, but on others you need to fiddle with env vars.
• Screen full of linker errors, because the linker for the host OS doesn't know what to do with the target OS's object files. It's less terrible if you enable a semi-secret option for bundled lld, but it's too buggy to use on some platforms.
Cross-compilation from one Linux flavor to another Linux flavor is reasonably easy with some distros. But anything more adventurous like Mac -> Linux just falls apart and you need to spend a whole day copy-pasting configs and installing bitrotting 3rd party Homebrew formulas from random people on the Internet.
Rust's tooling is usually excellent, but cross-compilation feels half-finished. The Rust's own side of it is fine (cross-compiles object files like a champ, has cross-libstd), but anything not written by the Rust project is left as "not our problem".
Zig is better C. I love zig.
Same here and I've been counting the days until my current project is finished so I can start one in zig
An extension of the zig ideas is making self contained portable and very small binaries that run everywhere from bare metal to any OS using a cross platform libc and configuring GCC or clang appropriately.
Check out cosmopolitan at https://justine.lol/cosmopolitan/index.html and background at https://justine.lol/ape.html
Aside: Zig and Zag were humourous puppet characters with attitude for adults in the UK. Always made me smile on the 'big breakfast' show in the 90s.
Check out cosmopolitan at https://justine.lol/cosmopolitan/index.html and background at https://justine.lol/ape.html
Aside: Zig and Zag were humourous puppet characters with attitude for adults in the UK. Always made me smile on the 'big breakfast' show in the 90s.
So I guess LLVM has rather poor fortran support, but zig fortran compilation would be really neat for all kind of scientific programming purposes.
Being able to call fortran code from zig as easily as one can call C libraries would also make it a really nice way to wrap fortran libraries into lightweight static programs.
Being able to call fortran code from zig as easily as one can call C libraries would also make it a really nice way to wrap fortran libraries into lightweight static programs.
On another note, it is possible to do a similar thing building msvc windows rust binaries on Linux with cargo + wine + windows wdk and some shell scripts...
Seeing wasmtime as the problem makes my brain itch a bit.
Wasn't there some big kerfuffle that the owner of wasmtime won't maintain it but won't hand it over?
Wasn't there some big kerfuffle that the owner of wasmtime won't maintain it but won't hand it over?
Wasmtime is actively maintained, and owned by the Bytecode Alliance. I’m not sure what project you are thinking of but it’s not Wasmtime. (Disclosure: I am a Wasmtime maintainer)
Not wasmtime, but I'm reminded of wasm-pack [0], though it's not project ownership but crate ownership, and not really a big kerfuffle.
[0] https://github.com/rustwasm/wasm-pack/issues/928
[0] https://github.com/rustwasm/wasm-pack/issues/928
I can't help but think every time it's mentioned: what a poor choice of a name for a programming language.
I like it. The only problem I've had with it is that searching for zig in YouTube gives me mostly children cartoons so I have to use ziglang. Not many other languages are much better though. Rust, ruby, java, python, they are all existing words with prior meaning.
Why is Zig a bad name?
I would go with Zag.
I have to respectfully but strongly disagree. No one is moving 'zags' for great justice
I may be mistaken, but isn’t it phonetically phonetically same as German “sieg”? As in, “sieg heil” (nazi salute)?
German here. First of all, "Sieg" doesn't have a negative connotation, it just means "victory", nobody in Germany automatically associates it with with "Sieg Heil".
Second of all, "Zig" doesn't sound like the German "Sieg", as the latter sounds more like the English "seek".
Okay, that's good to know. Thanks for taking time to explain. I'll have to correct my association then. Knowing that I was way off on that actually made my day better.
I heard this word in Eastern Europe countries exclusively referred to as a name for the neo-nazi salute.
I heard this word in Eastern Europe countries exclusively referred to as a name for the neo-nazi salute.
Glad I could clarify :)
Update: You really have to enforce the association like shown in this video: https://www.youtube.com/watch?v=U_SwFHtgJCQ
Here's an example repo with everything you need to give it a shot!
https://github.com/ifreund/zig-napi-example
This uses Node's N-API, which is actually a C header, but which is consumed perfectly from within Zig. And here are the relevant N-API docs: https://nodejs.org/api/n-api.html