ghc.v9_10_3_binary: fix the musl hash and two follow-ups to #178

[hhefesto]

Hi! I'm a bit ashamed to disclose that my ghc-9.10 PR was a bit of an overstep from my fable session.

I left it running last night before going to bed because I still had fable tokens and my weekly reset was at 2 am and I didn't want to waste them so I fired a flable 5.1 max session to port a project to ekala from vanilla nix and gave it instructions to fork and work on keeping ghc-9.10, and resulted in also doing a PR with not enough review. Sorry about that, I've fixed my permission settings.

I've been evaluating the PR and reviewing it and there are a couple of mistakes and a false claim that it works with HLS. Currently working on a haskell-pkgs PR to have that claim be true.
This is fable's description of what was wrong in my runaway PR:

What was wrong in #178

1. Wrong hash for the x86_64 musl bindist. The alpine3_12 entry carried the sha256 of ghc-9.10.3-x86_64-fedora33-linux.tar.xz, the neighbouring line in upstream's SHA256SUMS. Nothing in corepkgs builds the musl variant, which is why neither the build nor CI noticed. The other six hashes are right.
2. The "Checked" list overclaimed. It said haskell-language-server builds against ghc9103Binary (next to a leftover <!-- fill in what was actually built -->). It does not: HLS 2.13's formatters (ormolu 0.8, fourmolu 0.19) need Cabal-syntax 3.14 where GHC 9.10 bundles 3.12, so the closure ends up with two Cabal-syntax instances. cabal-install built only with Cabal 3.16 put in its scope. What did build on the set: a project with cabal-version: 3.12 and its test suites, plus hlint, stylish-haskell and ghcid. The HLS fix belongs in haskell-pkgs (its overlay is composed after the compiler configuration, so a compiler-config override is discarded); it is being prepared there.
3. An undisclosed side effect. The terminfo library-dirs fix was also applied to 9.8.4-binary.nix, which changes the default compiler's derivation and so invalidated its cache entry. The fix itself is right (the bindists' terminfo package links -ltinfo and finds it nowhere), but it should have been a separate commit and said so.
4. Inherited assumptions. 9.10.3-binary.nix is 9.8.4-binary.nix with the version and hashes changed, so it also inherited the x86_64-linux-ghc-<version> library directory hard-coded in the wrapper and recache steps for every Linux system. Only x86_64-linux was built; the other six platform entries are unverified copies.

This PR

• ghc.v9_10_3_binary: fix the x86_64 musl bindist hash — the alpine3_12 sha256 now matches SHA256SUMS and nix store prefetch-file of that tarball.
• ghc-binary: take the ncurses package from archSpecificLibraries — the terminfo fix now derives ncursesUsed the way gmpUsed is derived, in both bindists. The rendered path is identical, so neither derivation changes (checked by comparing drvPath before and after); no cache invalidation this time.
• ghc.v9_10_3_binary: stop hard-coding the x86_64 library directory — the two ghcLibDir= lines glob the arch directory instead. 9.10.3 only, to leave 9.8.4's derivation alone.

Verified on x86_64-linux: the rebuilt 9.10.3 bindist has the same file set and byte-identical wrappers (modulo store path) as before, passthru.tests.{hello,templateHaskell} pass, ci/eval.sh evaluates all 2071 packages, nixfmt is clean. The musl fix is verified by prefetch only, since there is no musl package set to build it with.

Not in this PR: HLS (haskell-pkgs, coming), and the per-version copy of the bindist file — with three copies whose diff is nine lines, a shared mkBinaryGhc { version, hashes } in generic.nix would be the next cleanup if you want it.

[hhefesto]

currently working on actually having HLS be able to build with this ghc-9.10, so you might want to wait until that resolves.

And thank you for this monumental effort! for ekala in general

[hhefesto]

haskell-pkgs PR was quite simple: ekala-project/haskell-pkgs#4

[hhefesto]

in fable's words:

The HLS half of this is now ekala-project/haskell-pkgs#4: it builds the HLS closure in a Cabal-syntax 3.14 scope in haskell-packages.nix. It had to go there rather than into configuration-ghc-9.10.x.nix because corepkgs composes the compiler configuration before config.overlays.haskell, so the snapshot's definitions win over anything the compiler config says about the same package. With that branch and this one, haskell.packages.ghc9103Binary.haskell-language-server builds and typechecks a real project on GHC 9.10.3, which makes the claim in #178 true at last.

[jonringer]

All good, if anything, this highlights that I need to clean up ghc bootstrapping.