Nice to have: armv7l-linux binary GHC in 9.2 or 9.4 series

[sternenseemann]

After #193037, we no longer have a 9.2.* bindist for armv7l-linux. This lengthens the bootstrap chain for ghcHEAD on that platform to ghc8107BinaryMinimal -> ghc924 -> ghcHEAD. This is not too bad, since ghcHEAD is mostly maintained as a testing ground for the upcoming, hadrian-based GHC 9.6. It would be nice to sort it out until that release comes out, though.

There are three options:

1. Ideally, GHC HQ fixes their armv7l-linux CI runners and publishes a armv7l-linux bindist for a new release in the 9.2 or 9.4 series (9.6 would not really help, since thanks to hadrian self-bootstrapping has become less viable).
2. We restore ghc922BinaryMinimal and drop all platform support except armv7l-linux, using 9.2.4 to bootstrap in general, but 9.2.2 for armv7l. I'd accept such a PR today.
3. We look elsewhere for bindists. @amjoseph-nixpkgs looked into reusing Debian's GHC packages as bootstrap seeds for GHC, but to no avail so far. One hope I have is that hadrian requires to build a bindist as an intermediate build artifact (which causes us much annoyance in the GHC derivation) which is installable anywhere in theory. Maybe other distributions with wider official platform support can be bothered to publish these bindist artifacts which would be easier for us to reuse.

[ghost]

3. @amjoseph-nixpkgs looked into reusing Debian's GHC packages as bootstrap seeds for GHC, but to no avail so far.

The main obstacle I hit is the fact that GHC writes absolute pathnames into its installed image in a very large number of places. After patching all of the pathnames I could find, and running patchelf, I hit extremely cryptic glibc link errors involving GLIBC_PRIVATE which led me to believe that I'd either missed some pathnames or done something wrong with patchelf.

It's not impossible; it's just less attractive than a longer bootstrap chain.

Hydra has machines which canExecute armv7l-linux, so uploading a blessed ghc924 built by Hydra to tarballs.nixos.org might be a better solution. This is basically the same thing as patchelfing Debian packages, except that we aren't outsourcing the build to Debian (could be viewed as a positive thing).

It's a bigger issue on platforms which none of Hydra's machines canExecute.

[ghost]

Also, how far did previous efforts at building ghc with hostPlatform!=buildPlatform get?

Unless there's some sort of enormous obstacle there, I think that's the most attractive long term solution. Then we could treat ghc the way we treat gcc in the bootstrap-files tarball -- cross-compile the seed compiler from whatever platforms Hydra supports.

IMHO in the long run this is the only sustainable strategy for nixpkgs to deal with compilers that are written in their own language.

[sternenseemann]

Also, how far did previous efforts at building ghc with hostPlatform!=buildPlatform get?

I agree with you that this is probably the best option for the long term – we should probably open an issue for implementing this. It definitely used to be possible, but:

• It regressed in hadrian, see ghc#22006 (ignore my initial misconception about the GHC build system in that thread).
• The way it works is quite ugly: You need to configure GHC the same as you would the GHC cross compiler targeting the host platform, i.e. you need to pass --host=${stdenv.buildPlatform.config}, --target=${stdenv.hostPlatform.config} (cross compiling a cross compiler is not possible at all!). The difference to the build->host cross compiler is then that you build until GHC Stage 2 instead of Stage 1, i.e. let the cross compiler rebuild GHC one more time – which will of course only be executable on the platform it targets.
• There would be a correctness issue for building a cross-compiled GHC: In an effort to shrink the shell wrapper for GHC (which isn't gone yet sadly) and to prevent the wrong tools from being used by accident I've started passing more and more absolute paths to GHCs configure step. The problem is that GHC's build system only really distinguishes between tools for build and tools for target (this is also a reason why you can't build a GHC with three different platforms) – this means practically that the build->target tools will leak into the final GHC, so building a GHC hinges on the invariant that build->target == host->target (in fact we have an assert for this). To cross compile GHC we'll need to work around this issue by modifying the ghc.settings file after the build process – this is hopefully the only place where these references exist.

Overall I think it's worth undertaking this, but it's a big job. Also GHC upstream doesn't test this (to my knowledge) and the whole thing feels a bit like an accidental possiblity. Getting this to work for hadrian would be great, since we'll be able to carry that forward, but realistically we'd also need it for make since hadrian seems to buggy on older GHC versions (which we'd need for bootstrapping) to switch.