ARM64 build on an Apple Silicon macOS host: toolchain builds after fixes (branch available)

Summary

I attempted an ARM64 build of ravynOS on an Apple Silicon macOS host (macOS + Xcode 26.6, bmake from Homebrew, bmake -j8 NO_ROOT=1 world), since Docs/BUILDING.md lists macOS as a build host and the top-level Makefile already derives BuildArch/CpuArch from MACHINE. As far as I can tell this is the first ARM64 attempt — ARCH_CONFIGS is hardcoded X86_64 upstream.

Result so far: the toolchain (LLVM/clang/lld/tapi, targeting AArch64 with aarch64-apple-darwin triples) builds to completion after the fixes below. The build is continuing into cctools/ld64 and beyond; I'll update if I get further.

Working branch with all fixes as separate commits: https://github.com/MaxLeggieri/ravynos/tree/arm64-build (happy to open PRs for any subset you'd take).

Genuinely ARM64-specific bug

• Developer/Default.xctoolchain/include/TargetConditionals.h has no __aarch64__/__arm64__ case — it handles ppc/ppc64/i386/x86_64/arm, so every arm64 compile fails with #error unrecognized GNU C compiler. Fixed by adding a TARGET_CPU_ARM64 branch.

macOS-host portability issues found on the way

1. Several toolchain Makefiles chown root:wheel unconditionally — guarded by .if !NO_ROOT, so NO_ROOT=1 works, but BUILDING.md doesn't mention it.
2. xar: openssl/evp.h — OpenSSL headers aren't in the macOS SDK (fixed by using Homebrew openssl@3 on Darwin hosts).
3. dtrace_ctf/libctf/qsort.c redefines qsort_r, which conflicts with macOS libc's declaration (different argument order). Guarded with #ifdef __APPLE__.
4. Developer/Default.xctoolchain/llvm/Makefile: -DCMAKE_C_FLAGS=${CFLAGS} is unquoted (the CXX one is quoted), so multi-word flags split and cmake errors with Unknown argument -fno-common.
5. The ravynOS target include dir is fed to the host stage-1 LLVM build, where it shadows the macOS SDK's mach/*; since mach/task.h is MIG-generated later, LLVM fails on undeclared task_{get,set}_exception_ports. Filtered the include for the Darwin-host stage-1 build.
6. tapi/tools/libtapi/libtapi.exports contains both libc++ (NSt3__1…) and old-libstdc++ (Ss…) manglings; on a libc++/Darwin host the libstdc++ entries can never resolve and -exported_symbols_list turns each into an <initial-undefines> link error. Used a filtered list on Darwin.
7. cctools/ld64/src/Makefile hardcodes libtapi.so; on a Darwin host LLVM produces libtapi.dylib. Parameterized the suffix.

Items 2–7 suggest the macOS-host path hasn't been exercised recently; if that's expected, a one-line note in BUILDING.md would save the next person some time.

Thanks for the project — this came out of evaluating ravynOS for an ARM64-based effort, and I'd be glad to keep pushing the branch along if there's interest.