Native nix build for old-gcc?

[andreadellacorte]

Hi! Following on from the macOS support work in #33 / #34 (build scripts) and #35 (HOST_WIDE_INT fix), I've been thinking about whether old-gcc would benefit from a nix-based build path.

Two motivations:

1. The linux Dockerfile path and the macOS .sh path drift from each other in subtle ways — xm-darwin: force 32-bit HOST_WIDE_INT to match Linux i386 reference #35 is a good example, the bug only existed on the macOS side because the Dockerfile passes -m32 and the shell script can't on Apple Silicon. With one nix derivation used on both, that whole class of issue disappears.
2. Local-CI parity. Right now a macOS contributor can't easily reproduce a linux-CI failure without spinning up docker, and a linux contributor can't reproduce a macOS-CI failure at all. With nix, anyone running nix build gets the exact same toolchain CI does, on whichever host they happen to be on.

I have a working proof on the macOS side: one flake.nix builds gcc-2.7.2-psx and produces a cc1 functionally identical to the current release tarball (verified by compiling a real ~4500-line TU and md5-comparing the .s output). The linux side is just nixpkgs stdenv on ubuntu, no cross-compilation needed - same flake, different host.

Two questions:

1. Are you open to migrating builds to nix? Either replacing the Dockerfile + .sh paths entirely, or running nix alongside them with the eventual goal of replacing.
2. If yes, would you want all 22 gcc versions covered in one go, or just the three with active macOS support today (2.7.2-psx, 2.7.2-cdk, 2.8.1-psx) first, with the others following later?

Happy to draft the PR if there's appetite.

[mkst]

I don't understand how this would work? Isn't the issue with building the mac binaries on Linux that Xcode has weird licensing agreement?

[andreadellacorte]

Hi there,

The proposal is just one shared flake.nix, which can run natively on each host:

• macos-latest runner → nix build → produces the mac binaries
• ubuntu-latest runner → nix build → produces the linux binaries

Same as today's CI matrix layout, only difference is both jobs will invoke nix build instead of one running bash *-macos.sh and the other running docker build. Each runner uses its own native SDK, no Xcode-on-linux weirdness.

The Nix flake itself serves as source of truth; both platforms read the same patches, same patch order, same configure flags, same compiler flags.

Today, instead, those are duplicated between the Dockerfile and the .sh script.