Hopefully the pains we feel with this shift to arm will inspire compiler developers to take cross compiling seriously. I don't see a reason why a compiler can't output binaries for any (or even ALL supported) platforms with a single CLI flag like golang does.
Golang can do this for the single reason of having no runtime dependencies whatsoever. Try it with literally any other language and you quickly find out that it’s no use crosscompiling to armv7 ‘in one click’ when your target doesn’t have the version of libc you’re targeting. The problem is not the compiler, it’s the build tooling.
Zig and Nim both have excellent cross compiling support out of the box.
Zig extends that excellent support to its embedded LLVM C compiler - it’s probably the easiest way to cross compile C across operating system boundaries these days.
musl is a Linux libc, so you can't use in on any other OS (because it wouldn't know how to send syscalls to the kernel).
macOS handles libc a little differently from Linux; whereas the Linux kernel publishes its syscall API, and allows programs to make syscalls however they want (e.g. with glibc or musl, or with go, which does syscalls itself), macOS's syscall API is subject to change at any time, and the only (supported) way to make syscalls is to dynamically link to the system libc.
Nim always relies on an underlying platform compiler.
Getting an .o out from a cross compiler is easy, in my experience - the big problem is getting libraries, includes and linkage right. And in my (admittedly small) experience, Nim makes that part much simpler as soon as you have a compiler set up (which in my case was an apt-get away)
But do note the apt-get doesn’t get you far. You now have a compiler that can produce .o, but headers, libraries, borked make files that are unaware of cross compiles etc are still a problem.
Can it do this anymore on macOS? My understanding was that they were going to start linking to libSystem, as they should, because otherwise golang apps can and will break between major macOS releases.
(Not to mention the golang folks' need to reinvent the wheel has caused a few high-profile bugs that have needlessly wasted people's time.)
Regardless, this quickly falls apart whenever you have an app that does any kind of FFI to system libraries, or even third-party libraries that the author didn't want to reimplement in golang.
FFI can work - P/Invoke with C# for example doesn't care if you're cross compiling or not, but it comes at the cost of needing a definition of the interface in your code.
Windows makes cross compiling work by shipping the libs for each of the architectures in the SDK. I think that's quite reasonable for macOS since Apple controls the SDK, but it's always seemed to be a mess on Linux.
Disclaimer: I work at Microsoft on Windows but I have tried cross compiling code on both Windows and Linux in the past and I've always found it painful on Linux.
You can, I think, link to libSystem dynamically without actually having libSystem to refer to. At least, you can output a macho file that calls a function in a dynamically linked library when all you know is the name of the function.
If anything the M1 Mac reduces the case for cross-compilation since they're actually fast enough to build code on. Compare that to e.g. compiling hefty C++ projects on the Raspberry Pi where cross compilation on a fast x86 box is ideal (but still far from trivial).
For non-trivial projects you want CI anyway so it's a better ROI of your time to just to add an additional VM, Docker or native runner.
And let's not forget you'll also want to run your automated tests in the native environment.
