3 ms·
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.
by 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 agoRust 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".