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:
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!
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)
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".
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.
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 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.
On a related note, if you've mostly spent time with JavaScript, and you've always wanted to write a fast native binding for Node.js but didn't know any C, or if you ever had issues with the node-gyp build system, then you can even use Zig to write and compile native bindings for Node.js, without a line of C, and without any node-gyp:
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
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...
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)
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.
24 comments
[ 0.21 ms ] story [ 62.1 ms ] threadhttps://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.
Either way, hope Zig and Rust continue to inspire each other a bit!
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)
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".
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.
I heard this word in Eastern Europe countries exclusively referred to as a name for the neo-nazi salute.
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
Wasn't there some big kerfuffle that the owner of wasmtime won't maintain it but won't hand it over?
[0] https://github.com/rustwasm/wasm-pack/issues/928
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.