macOS Intel (x86_64) — it already builds and runs, here's what it took #178

Before you continue

• I searched the existing issues and nobody has suggested this yet.
• This is about WiiCompiled itself, not WheelWizard or Retro Rewind content.

What would you like to see?

runtime/CMakeLists.txt currently says:

The first native macOS target is Apple Silicon. Intel and universal binaries
remain future compatibility work; do not silently claim them.

I'd like to see that supported, and I think it's closer than the comment
suggests: I built it and it runs. Posting the findings in case they're useful.

Tested on: MacBookPro13,1 (Skylake, Intel HD 520), macOS 26.6.2, base game,
clean PAL RMCP01. Solid 60 FPS in-race. I also verified the x86_64 slice under
Rosetta 2 on an M4 first, which is a practical way to iterate without owning an
Intel machine.

Almost nothing platform-specific had to be written. Every arch-dispatched
path already has an __x86_64__ branch proven by the Linux target, and every
macOS-specific path already exists for arm64. The port is mostly crossing the two:

• guest_flat_memory.h dispatches on arch, so Intel lands in the existing
  __x86_64__ branch (16 TiB base), and guest_flat_memory_macos.cpp is pure
  Mach VM with nothing arm64 in it.
• HostContext was the only macOS piece that was arm64-only (co_switch.S).
  The vendored libco already ships amd64.c, so macOS x86_64 can use the same
  backend Linux does — no new assembly.

What actually needed changing:

1. The platform gate in runtime/CMakeLists.txt; building mkw_libco and
   linking mkw::libco on macOS x86_64 (both link points are currently gated on
   MKW_PLATFORM_LINUX); and skipping co_switch.S off Apple Silicon.
2. host_context.cpp: let the libco branch accept __APPLE__ && __x86_64__.
3. main.cpp, PosixMemoryFaultHandler: uc_mcontext.gregs[REG_ERR] is
   glibc-only. On Darwin uc_mcontext is a pointer and the page-fault error code
   is at uc_mcontext->__es.__err. Also <ucontext.h> demands _XOPEN_SOURCE
   on macOS while <sys/ucontext.h> provides just the types, which is all this
   handler needs.
4. On Apple platforms the effective architecture is CMAKE_OSX_ARCHITECTURES,
   not CMAKE_SYSTEM_PROCESSOR — the latter keeps the host's value unless the
   caller opts into full cross-compiling. Keying the platform gate and
   MKW_BASELINE_ARCH_FLAG off the effective arch avoids -mcpu=native reaching
   an x86_64 target.

-march=x86-64-v3 is fine here: every Mac that runs macOS 14+ is Haswell or
later, so the AVX2 floor is already met, and Rosetta 2 handles it too.

A universal binary works as well — lipo on the two slices, one .app that runs
native on both.

I'm happy to open a PR for those four changes if that's welcome.

Workarounds you've tried

Two things outside the runtime that I had to work around, in case they save
someone else the time:

Dawn package selection. aurora's provider picks the prebuilt by
CMAKE_SYSTEM_PROCESSOR, so a cross-compiled x86_64 build downloads the arm64
Dawn and fails at link with undefined wgpu* symbols.
dawn-darwin-x86_64.tar.gz does exist in the pinned release, so
-DAURORA_DAWN_PACKAGE_URL=... is enough. A native Intel build picks the right
one by itself, so this only affects cross-compiling.

Shared libraries in the app bundle — this one may also apply to #151.
aurora links libpng, abseil and friends as shared unless BUILD_SHARED_LIBS is
defined, and publish-app.command only bundles dylibs found under
/opt/homebrew or /usr/local. An @rpath/libpng16.16.dylib pointing into the
build tree therefore gets copied nowhere, and the app still runs perfectly on the
machine that built it. It dies in dyld on any other Mac:

Library not loaded: @rpath/libpng16.16.dylib
tried: '<build dir>/_deps/png-build/libpng16.16.dylib' (no such file)

-DBUILD_SHARED_LIBS=OFF fixes it. otool -arch <arch> -L on the shipped binary
catches it before shipping — anything outside /usr/lib/ and /System/ won't
exist on the target machine.