An x86_64 macOS runtime under Rosetta compiled every overlay shard for
arm64. The runtime's shell and the bundled Python inherit x86_64, so
compile_overlays.py named the cache macos-x64, but it ran the compiler
without -arch and Xcode's clang is an arm64-only binary that defaults to
arm64. The arm64 shards landed in the macos-x64 cache, the runtime could
not load any of them, and every overlay ran interpreted. The BIOS module
builder had the same compile line.
- overlay_loader.h now defines PSX_OVERLAY_ARCH_ABI (moved from
overlay_loader.c), and autocompile.c exports it to every compile it
spawns, next to PSX_OVERLAY_FLAVOR. It is the running slice of a
universal binary.
- compile_overlays.py adopts it (env wins over the new --arch-abi), names
the cache with it, and passes -arch on macOS. Without a pin it builds
for its own interpreter, still with an explicit -arch.
- Shards are validated by loading them into the Python that built them,
so a Python that cannot run as the runtime's architecture now refuses
up front instead of writing shards nothing loads. The Python's
architecture is its process's: platform.machine() on macOS and Linux,
the interpreter's build (sysconfig.get_platform()) on Windows, where
platform.machine() reports the machine. So an x64 Python emulated on
Windows on ARM still builds the x64 runtime's shards.
- psx_bios_module.c passes --arch-abi to bios_module_build.py, which
applies the same rules.
- Windows and Linux compile lines are unchanged, and so are their cache
directories, except that the x64 build on Windows on ARM now uses the
runtime's win-x64 instead of the machine's win-arm64.
overlay_compile_arch_test (CTest) pins the handoff, the flags, the refusal,
the Windows process architecture and the unchanged Windows/Linux commands;
with a real cc it builds a shard for each slice the Mac can run and loads
it in a process of that architecture.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Shokunin