haskell.compiler.ghc924Binary: drop

[emilazy]

Proposal per #440794 (comment). Stacked on top of that PR; only the last two commits are relevant. Untested.

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[wolfgangwalther]

I have not finished that, yet, but early experiments are promising to bootstrap GHC 9.6.7 with 9.6.3 bindist. So I guess that could be an option as well.

[emilazy]

In that case, though, we would either have to not move forward with #440410 and implement this change to make 9.6.3 bootstrap via 9.4.8, or have version divergence between using the cross‐compiled 9.4.8 bootstrap tarball vs. the 9.6.3 binary distribution.

[wolfgangwalther]

I don't know the "cross‐compiled GHC 9.4 bootstrap tarballs" plan, so I can't really judge which way is best. I'm just generating options to choose from :)

[emilazy]

I’m not sure if I fully know it either, but my understanding is:

• GHC 9.4.8 is the last GHC we can cross‐compile, for now. So we have no way of producing a GHC > 9.4.8 binary with a hostPlatform that we don’t already have a GHC for.

• We can, in fact, cross‐compile GHC 9.4.8: I built an unregisterized GHC 9.4.8 that ran on RISC‐V while testing my recent changes, and that would at least try to compile programs via the C backend. (I did not set up enough binfmt machinery to confirm that it could, in fact, compile those programs, or that the compiled programs would run.)

• For newer architectures like RISC‐V and LoongArch64, you’d need to either accept an unregisterized via‐C thing, or you’d need to backport proper support for the architecture to 9.4.8. ARM and PowerPC shouldn’t have this problem, as they were presumably reasonably well‐supported even in 9.4.8, with PowerPC even having a native code generator.

• So, we can get Hydra to cross‐compile (a static build of?) GHC 9.4.8 for a prospective new platform, in the same way that Hydra will cross‐compile the stdenv bootstrap tools for such architectures.

• Then we can do the same dance of getting the infra team to upload that to tarballs.nixos.org, and package it up as a native binary package for the architecture. (See e.g. make-bootstrap-tools-cross: add powerpc64-unknown-linux-gnuabielfv1 #419955 and pkgs/stdenv/linux: add powerpc64-unknown-linux-gnuabielfv1 bootstrap-files #423133.)

• Now we have a ghc948Binary package for the platform. As long as we can construct a bootstrap chain from a GHC version back to that, it can be built natively on the platform.

This means that if we care about supporting a GHC version on a platform, and its bootstrap uses ghc963Binary and we don’t have a source‐based ghc963 any more, then we have a problem, and would need to diverge and construct an alternative bootstrap path.

IMO, given 9.4.8’s unique status at present, it makes sense to prefer it for bootstrap paths. Whether that should be by using the source‐based ghc948 or by packaging a ghc948Binary in preference to a ghc963Binary, I don’t know.

I don’t even use any of this stuff…

[wolfgangwalther]

I don’t even use any of this stuff…

Your work is very much appreciated, though :)

[emilazy]

Well, I spent a good few years as a Haskeller, so I have lingering sympathies even if your Nixpkgs infrastructure scares me :)

I’m undrafting this, since the obvious issues have been resolved and it still seems like the right direction to me: if 9.4.8 is going to be a load‐bearing part of bootstrap paths, then it should be used as such consistently, and if we’re stuck with 9.4.8 for now anyway, then it’s better to rely on it than adding 9.2 into the equation just for (non‐exotic) bootstrap purposes.

I have not actually confirmed that the bootstrap works, and even if it does, @sternenseemann will presumably have more enlightened opinions than I about whether using the source build here makes sense, or whether we should introduce a ghc948Binary using the official tarballs.

[sternenseemann]

Looking into ghc948Binary.

[emilazy]

Will rebase this after #444249.

I am no longer sure ghc948Binary makes sense, at least in the short term:

• GHC 9.6.7 isn’t the default compiler, and we already have GHC bootstraps that hop through one source build. Introducing one more doesn’t seem like a big issue, as long as the chains don’t get longer than that on common platforms.

• We need ghc902Binary to cross‐compile GHC 9.4.8, and we really want a more modern binary to make the bootstrap chain of the default compiler short. After haskell.compiler.ghc963Binary: drop #444249, that would be ghc984Binary. Re‐introducing a third binary distribution seems undesirable unless it’s necessary.

• Cross‐compiled GHC 9.4.8 binary distributions would be a good reason for it, but would we want to bundle those in with a standard ghc948Binary? The provenance would be quite different, more like bootstrap tools. The Debian binary packages people have been experimentally bootstrapping new architectures with were different enough that you asked to separate them out. Would we be producing tarballs of the exact same format? I guess we would probably want to statically link the result? Anyway, it seems sufficiently unclear to me that assuming a ghc948Binary package for standard platforms could have shared logic with those seems premature, but maybe you have a better idea.

• AIUI, the Cabal‐driven GHC bootstrap you said you planned to look into soon would allow cross‐compiling of modern GHC versions and fix static TH – at which point, these versions would become nothing special and we wouldn’t need to carry them around longer than the Nixpkgs GHC support policy. GHC 9.4.8 would be immediately eligible for removal, and 9.6.7 when GHCup recommends a newer version and we bump our default to 9.12. We wouldn’t have any particular desire for bootstrap binaries of GHC 9.4.8 specifically at that point.

Maybe I am missing something, but going through the GHC 9.4.8 source build seems like the sensible option for now.

[wolfgangwalther]

@emilazy can you rebase after #444249 is merged?

This means you will need to target staging here.

[emilazy]

Done.

[wolfgangwalther]

Tested:

• ✔️ x86_64-linux
• ✔️ x86_64-linux musl
• ✔️ aarch64-linux
• ✔️ i686-linux
• ✔️ aarch64-darwin

Beautiful.

(Edit: to clarify, I tested the bootstrap path on master to avoid rebuilds)

[wolfgangwalther]

Merging to allow all builds in #440774 to actually test the things we are going to ship for 25.11, without having to test all these again, if we merge them in the reverse order.

[wolfgangwalther]

Looking into ghc948Binary.

I'm not exactly sure whether that refers to "bootstrap GHC 9.6.7 from GHC 9.4.8 bindist" or "cross-compile ghc948Binary via tarballs". In either case, we should be able to do it once you have results and don't need to block here.