[Upstream] Compiler segfaults when built on systems with >~32 cores

[pluiedev]

See #8676, ziglang/zig#22867, NixOS/nixpkgs#445326, NixOS/nixpkgs#446056

The Zig compiler may crash when compiling Ghostty due to a memory corruption bug triggered when too many logical cores ("CPU threads") are detected on the system (the empirically determined threshold seems to be around 32 logical cores). Due to the complex and fundamental nature of said bug, it's non-trivial for either Ghostty or the Zig compiler to fix the root issue.

Users and packagers who are failing to build Ghostty because of this should use CPU scheduling utilities (like taskset(1)) to manually limit the number of available cores to the compiler, as follows:

maxCores=$(nproc)
coreLimit=$((maxCores < 32 ? maxCores : 32))

# Omit the `-Doptimize` flag for a debug build
taskset -c "0-$((coreLimit - 1))" zig build -Doptimize=ReleaseFast

Note that the -j flag does NOT affect this bug. The Zig compiler seems to always use all available cores in the system regardless of the setting, so it's necessary to use taskset(1) or another equivalent utility to force Zig into using fewer cores.

This bug primarily affects Ghostty 1.2, although reports say that 1.1.3 is also impacted on extremely parallel processors like Threadripper and EPYC CPUs with more than 128 logical cores. We're currently working with Zig maintainers to address this bug at its core, and a fix is projected to be included in Zig 0.15.2. An effort to port Ghostty to Zig 0.15 has been underway for quite a while (see #8372) and depending on the impact of this issue, the earliest Ghostty version to target Zig 0.15 could be either 1.2.1 or 1.3.0. More news should follow soon.

[mitchellh]

I think we can close this since now have a workaround in #8925, yes? Once the upstream bug is removed we can remove that.

[pluiedev]

I think this can be closed, yeah.