haskell.compiler.ghc984: self-bootstrap on aarch64 musl

[alyssais]

GHC only provides bootstrap binaries for aarch64 musl since 9.8.x, so we can't bootstrap with the recommended 9.6.x in that case. Fortunately, bootstrapping with 9.8.x seems to work fine.

Some notes:

• So far I've only confirmed that 9.8.4 builds. I've changed 9.8.1–9.8.3 as well, assuming that they'll build too.
• I've left every other platform bootstrapping 9.8 with 9.6. Is that the right thing to do, or would it be better to bootstrap with 9.8 across the board for consistency?
• I haven't made any attempt to factor out common stuff between the expressions for the bootstrap binaries, as it doesn't look like this has been done before. They also all seem to need slightly different fixups, and them presumably very limited maintenance thereafter, so probably not worth it?

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[alyssais]

Aaaa, I think my test build was not actually a musl one. This probably needs some more work…

[alyssais]

Okay, that's better. Still wasn't too bad…

[alyssais]

Result of test builds: 9.8.1–9.8.3 fail to build, but 9.8.4 (the important one) works.

[sternenseemann]

I've left every other platform bootstrapping 9.8 with 9.6. Is that the right thing to do, or would it be better to bootstrap with 9.8 across the board for consistency?

If possible, this is preferrable, I think, but we probably don't have to change this right away (maybe do it via staging later?). Bootstrapping GHC is quite fragile (e.g. some weird RTS stuff needs to match), so everything not tested/supported by upstream may break even between minor versions (we've experienced this with self bootstrapping in the past). Since aarch64-musl isn't really exercised on CI as prominently as other platforms, it's probably best to always use the self bootstrapping path to avoid accidental regressions. For the obscure targets e.g. powerpc and armv7l that need to use a source built GHC, it's necessary to keep using 9.6, of course.

I haven't made any attempt to factor out common stuff between the expressions for the bootstrap binaries, as it doesn't look like this has been done before. They also all seem to need slightly different fixups, and them presumably very limited maintenance thereafter, so probably not worth it?

Yes, this has been my conclusion so far. I think going forward we can probably make a common expression since all bindists are theoretically produced in the same way since 9.6, but I haven't had time to look into it yet.

[alyssais]

Bootstrapping GHC is quite fragile (e.g. some weird RTS stuff needs to match), so everything not tested/supported by upstream may break even between minor versions (we've experienced this with self bootstrapping in the past).

Given this, I've dropped it from 9.8.1–9.8.3 where it didn't build, and left it just for 9.8.4. Still aarch64 musl only for now, but I'm happy to investigate building 9.8.4 with the 9.8.4 bindist where possible as follow-up after this PR is merged.

[sternenseemann]

We should merge this into staging directly as to not interfere with the stabilization of the new haskell-updates rotation. the addition of the new bindist could be picked onto master directly, but not sure whether it's worth it. Overall it looks good to me, I'm running some sanity check builds now (though not on aarch64-linux since I don't have a machine available at the moment, but I trust you tested that…).

[sternenseemann]

Do you know whether this will overwrite config.sub / respects dontUpdateAutotoolsGnuConfigScripts? Otherwise this is a problem since GHC ships a non standard config.sub which is important for ghcjs.

[sternenseemann]

I was able to build a ghcjs cross compiler, so it seems to be alright.