3 ms·

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

by bsaul 5y ago

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 ?

pornel 5y ago
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-replacement-gcc-clang.html 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.
- ArthurBrussee 5y ago
  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!
- 3836293648 5y ago
  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)
  - pornel 5y ago
    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".

by bsaul 5y ago

pornel 5y ago

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-replacement-gcc-clang.html 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.

ArthurBrussee 5y ago
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!
3836293648 5y ago
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)
- pornel 5y ago
  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".