I’m a fan of the BSDs and how they differ from each other, Windows and Linux as operating systems. Mac OS (Darwin/XNU, if you want to be specific on the official name of the underlying system) is one of the most well known and popular BSD variant. It’s also seemingly not used all that often for cross-compiling to other BSD variants. I usually see Linux cross-compilers, so I figured I’d test it out some.
Over the past few months, I’ve been experimenting with the zig compiler and will be using that as the main cross-compiler for my tests since it mostly doesn’t rely on platform specific libraries or headers (or sysroots) to target other platforms. As found here, FreeBSD had an interesting quirk that would have not been found on Linux or Windows cross-compilations: if one doesn’t explicitly pass —os:FreeBSD to nimble when targeting x86_64-freebsd-none or x86-freebsd-none, the code would still compile as if it was targeting Mac OS and would require the bare minimum Macos SDK installed due to Mac specific headers being called.
OpenBSD and NetBSD both also require the —os flag but initially, the Macos SDK wouldn’t be needed since the majority of the build failures seem to be different implementations of common headers and functions. Dragonfly(BSD) is currently not fully supported yet but is being worked on as a Zig target. I don’t know exactly what’s going on with GhostBSD in that sphere, though.
Thank you for reading If anyone has interest in this subject or have experiences you’d like to share, feel free to comment below.
Not trolling one bit. Just fascinated in alternate operating systems, toolchains and cross-platform support.
About testing, there’s a few ways to do such: running on virtual machines, or in my case, running on hardware due to having multiple systems. This isn’t the most ideal thing due to running in a virtual machine within a virtualized environment but at least FreeBSD has a third party Github runner that works fairly well (albeit slow), especially after adding caching of build dependencies.
That’s fair. Now, is such a topic unwelcome?
There’s advantages and disadvantages to cross-compiling software and building from one source (such as a single Docker container) or building everything from multiple systems or even requiring the user to always build everything themselves.
Now, is such a topic unwelcome?
No, but I've yet to see these so called "advantages" of a setup that by its nature is much more complex than "let's run the compiler on the VM too". Do the math yourself: Cross-compiler from N machines to M targets: Testing matrix N*M for the compiler. Compiler from 1 host to 1 target: 1*1. And what gain is there from the N*M compiler complexity? Basically none. And do you enjoy unreliable compilers and ever more complex builds and toolchains? Because I don't.
Now of course, as a compiler dev, I'm super biased here, but the math doesn't lie.
I've recently experimented with cross-compiling binaries for OpenBSD from macOS.
With Rust you have to install additional toolchains, so I didn't even bother. Zig couldn't do it for now; maybe one day.
Unfortunately, both Rust and Zig have only Tier 3 support for OpenBSD. Too bad, as it's such a great, security-focused OS.
I've asked Grok about Nim's cross compilation capabilities, and it basically said "masochists only". His words not mine. :))
On the other hand, I've discovered Go has excellent cross compilation capabilities out of the box. It's incredible. You just:
GOOS=openbsd GOARCH=amd64 go buildand boom, binary is ready. Amazing!
If you don't want to setup a CI pipeline or maintain additional build machines, I think cross-compilation is great. At least for small projects.
If you don't want to setup a CI pipeline or maintain additional build machines
Do I understand correctly we're talking about shipping binaries that no one even tried to execute once?
I still don't understand.
Internal tools, utilities --- if someone in the company is using it, it means he has the hardware. Why not build there? Automation --- if you have access to the machines your code will run to deploy it, how come you can't build there?
How do these uses benefit from distributing non-tested binaries exactly?