Speaking of cross compilers - I was able to use the zig toolchain in order to cross compile for macos apple silicon, arm Linux, windows x64, windows arm and x86_64 Linux musl (statically linked). It's super handy and works as a drop in.
Dependencies in build.zig.zon are downloaded in to ~/.cache/zig/p/<hash> (incidentally, this means you need to mangle the hash if you are copying and pasting the hash for a dependency, at least currently. Dependency hashes are a sore spot tbh, and needs to be better)
Then when you are using said dependency in your build.zig, the function provided will refer to that source artifact in .cache.
At least this seems to be the case. I write a decent amount of zig, but haven’t dove too much in to the build system till recently, when I tried (and failed due to translate-c bugs), to get some C libraries added to zig using only zig build.
.dependencies = .{
.zstd = .{
.url = "git+https://github.com/facebook/zstd.git#v1.5.5",
.hash = "1220185ad79a437fd9f148d1422ff756287534c79a0712105039b4034031480e41a9",
},
},
https://github.com/floooh/sokol-tools/blob/master/build.zig
Here is a tutorial: https://www.zvm.app/tutorials/zig-build-cpp.html
I’m curious what the blockers are for rustc to cross-compile like zig does natively.
You can specify your own linker if you want, mold is a very popular one, and cargo-zigbuild does the same behind the scenes with zig cc as the linker.
I did something similar a couple of months ago (or a year ago? I don't remember exactly). I managed to cross-compile to windows-msvc on Linux using Wine, there's a project that provides the scripts to make this easier, including the linker wrapper: <https://github.com/est31/msvc-wine-rust>. It was just for fun because Rust can already target windows-gnu and it'll use mingw64 linker.
Rust's approach to things is normally to provide the basic foundation and let the community build on top of it. I personally like this approach, but it also has this downside of people not knowing they may need an external/community built tool to accomplish what they want.
Zig ships all the bits you need for a C/C++ toolchain including things like the C library in some cases (IIUC).
Rust could use libclang to make a "rustc cc" just like zig's. But I get the sense that it is probably not a goal of the project to have this functionality.
Now, you can download all the necessary files from a Mac and build a cross-compilation toolchain on your Linux system. I believe you could not legally distribute a project doing this and that is why these projects don't exist or are usually short-lived (with the notable exception of zig).
We will see how that goes for OP.
So, solutions like osxcross resort to shipping scripts that help you to acquire the necessary files and make that process easier.
The OP builds on osxcross, but is "batteries included".
zig has an even more difficult problem to solve because it tries to compile and link for many platforms. Shipping all the different requirements in their original form would make a zig distribution huge. So it does some clever magic I do not fully understand to create the necessary files from just the necessary subset of data. This reduces the size because there is overlap between platforms. It also means that they are not shipping the Mac files in their complete and original form and have gotten away with this legally so far.
At least that is what I believe is happening. I hope someone with more knowledge about zig could explain it better.
Rust did not do the legwork that zig did to bundle libc and a working linker, and Cargo is exceptionally naive in its default configuration, so it won't even find a usable cross-linker on the system, nor even try the chronically-unfinished rustc-lld integration there is.