Zig can cross compile and link libc on lots of different architectures out of the box, which is amazing given how much effort this takes to set up cross compilers normally.

saurik's reply to your comment feels to me like the epitome of the seasoned C/C++ developer _who is able and willing_ to put up with the tooling setup pains that make C/C++ a non-starter to the "average" developer today.

You can absolutely set up a cross-compiling C/C++ toolchain today as he said - but you're going to have to find the right packages in your distro, deal with the MacOS linking issue, get a copy of the android NDK, make sure you're installing the right package versions, muck around with libc, etc. That doesn't make for a delightful start to a new weekend project.

It's often underestimated just how substantial "setup pains" are IMO. I suspect most people who have a strong distaste for C/C++ mostly despise the tooling and installation hell.

The novel part of what Zig, (and maybe Rust/Go to a lesser extent) are doing with cross-compilation is not 'making cross compilation possible' - it's having 'the best experience' out of the box, with zero installation pain.

Zig has a ton of issues and is super early stages still.

But shipping out-of-the-box with a Zig/C/C++ cross-compiler, with libc, static libc(musl), compiler-rt, libunwind, libcxx, etc. for ~50 cross-compilation targets, and solving the MacOS cross-compilation linking issue (with their customer linker, zld) is IMO a huge deal because it lowers the barrier to entry to systems programming quite substantially.

> saurik's reply to your comment feels to me like the epitome of the seasoned C/C++ developer _who is able and willing_ to put up with the tooling setup pains that make C/C++ a non-starter to the "average" developer today.

For me the best example I currently have of such attitude is how an internal WinDev group managed to push for getting C++/CX replaced with C++/WinRT without it being production ready.

After 4 years, still no Visual Studio support for IDL files, one has to manually copy/merge generated files into the Visual Studio project, no two way editing with XAML files, we get continuously told that it only will be fixed when ISO C++ gets compile time reflection.

Apparently they feel that is a productive experience and never came close to try out either C++ Builder or QtDesigner.

I guess they were still using raw C to deal with COM to consider this kind of downgrade as something positive.

FWIW, this isn't actually difficult: you just need a sysroot, and past that you can just use clang (maybe ironically, for any platform other than Apple ones, as there still isn't a good common linker for mach-O; like, this still works fine, but it is in fact very annoying--but not impossible--to compile a macOS binary from any platform other than macOS). To cross-compile to Linux you can just download a handful of rpm files (the kernel and libc header packages, as well as the gcc package for the CRT) from CentOS or deb files from Ubuntu and extract them to a folder, and for Windows you just need a handful of Msys2 packages (the same general set). That's really all you need: my current major project--Orchid--compiles for Linux, macOS, iOS, Android, and Windows, and does so using the Android NDK copy of clang (just because it is easy to install and easy to ensure us always "the same" on every machine: I do cross-compiled reproducible builds). As long as you are using C/C++ it really should be easy to cross-compile (and yes: this is saurik saying something not only good about clang but specifically saying they finally nailed this use case, which they really hadn't a while back when people kept touting this as a feature... they really did eventually nail it). (That said, I do appreciate that not having to download and extract those packages is certainly "more convenient" than doing anything at all, but I just want to point out that it really isn't that "much effort".)

This sounds a lot more difficult than using Zig where you just need to find the right build flag. Maybe it's easy once you already know which exact packages to get for each platform, where to put them and how to tell clang about them. But if you don't know this, researching this can easily take hours, at least for me.

your solution would not support:

* specifying target cpu features (important!)

* features such as thread sanitizer support

* LTO that crosses the libc boundary

* targeting any glibc version

...all of which are supported out of the box by zig.

1. Do you have a blog post with exact instructions for this for some of the platforms? 2. Does this include targeting any gnu libc version (backwards compatible)? This would be very surprising to me.

The macOS D compiler cross-compiles to iOS, x86_64, and arm64. It just ships with 3 standard libraries built for those arch.