* Links MachO binaries for Apple Silicon via the custom zld linker it ships. LLVM cannot do this currently.
* Provides (deduplicated) libc headers for pretty much every platform, including macOS and glibc/musl. https://github.com/ziglang/zig/tree/master/lib/libc/include
* Provides a libc implementation (libSystem for macOS, musl and glibc, mingw for Windows, and WASI)
* Deals with lots of the deep depths of hell, like enabling you to target any version of glibc out of the box by building symbol mappings: https://github.com/ziglang/glibc-abi-tool/
And that doesn't mention the most important part, IMO, which is that it lets you cross compile _out of the box_. No fiddling with sysroots, system packages, etc. to get a cross compiling toolchain working.
Also, does it also work with build systems like CMake flawlessly? (I know that you can use Zig as a build system, but I would still want to leverage the ecosystem of C++ libraries compatible with CMake.)
It should be possible to use Zig as clang replacement in traditional C/C++ build systems, just by replacing the compiler invocation with 'zig cc', although I heard this sometimes causes subtle problems because of the space between 'zig' and 'cc', so it probably needs to be wrapped with a script file or maybe alias.
It wraps clang, so it supports whatever clang supports, C++ included.
> Also, does it also work with build systems like CMake flawlessly?
I haven't personally tried it, but I'd expect that if all else fails you could add a step in build.zig to run CMake and then link against whatever library you just built.
This would be huge. How can I tell zig cc to use a particular glibc version though?
I gave it a try and was very impressed.
Wish it could default to on with clang, but probably it'd break too many things. Really wonder how many severe issues we'd find just from turning this on by default everywhere, though.
[0] https://devlog.hexops.com/2021/perfecting-glfw-for-zig-and-f...
that’s… a great idea.
The main difference is that Clang does not ship with headers/libraries for different platforms, as Zig appears to do. You need to give Clang a "sysroot" -- a path that has the headers/libraries for the platform you want to compile for.
If you create a bunch of sysroots for various architectures, you can do some pretty "easy" cross-compiling with just a single compiler binary. Docker can be a nice way of packaging up these sysroots (especially combined with Docker images like manylinux: https://github.com/pypa/manylinux). Gone are the days when you had to build a separate GCC cross-compiler for each platform you want to target.
My scripts are the create-sdk-... Here if that can be useful to anyone: https://github.com/ossia/score/tree/master/ci and the SDKs are available at https://github.com/ossia/sdk
It makes me wonder whether cross-language tooling could be made to work more broadly. It would be awesome if you could have one compiler that would seamlessly compile zig/C/C++/Rust, and perhaps Fortran/ADA too.
what about the mac-os(or linux,etc) native libraries on windows where you're building the demo code? The 60MB zig compiler and native clang on Windows will not have them, how is that done? Is it totally on clang side?
At work we could not for that reason use the same compilation server setup to cross-compile for Linux, MacOS, Windows and ended up with a separated MacPro box for the compilation farm.
EDIT: cross-compilation from Windows works after one gets Windows SDK and Visual Studio libraries (the later is not free, but free alternatives often are sufficient). The biggest headache is that Windows headers assume a case-insensitive file system and includes, for example, windows.h when the file is Windows.h. One can either use case-insensitive mount option for ext4 or symlink relevant files to the proper case.
If you need the rest of the Apple SDK, then you'd need a sysroot (and face the challenges you described.)
Another Clang-specific way to handle the case insensitivity is by making use of a virtual file system (VFS) overlay. https://github.com/llvm/llvm-project/blob/4976d1fe58f89169ef... demonstrates how that works. (There's no linker equivalent that I'm aware of, so you do have to use the symlinks or something like ciopfs for that; https://github.com/llvm/llvm-project/blob/4976d1fe58f89169ef... is an example of symlink generation.)
Plus, it makes cross-compilation really easy.
In addition to being its own programming language and build system as well.
