Open sternenseemann opened 2 years ago
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 patchelf
ing 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
.
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.
Also, how far did previous efforts at building
ghc
withhostPlatform!=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:
--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.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.
After #193037, we no longer have a 9.2.* bindist for
armv7l-linux
. This lengthens the bootstrap chain forghcHEAD
on that platform toghc8107BinaryMinimal
->ghc924
->ghcHEAD
. This is not too bad, sinceghcHEAD
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:
armv7l-linux
CI runners and publishes aarmv7l-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).ghc922BinaryMinimal
and drop all platform support exceptarmv7l-linux
, using 9.2.4 to bootstrap in general, but 9.2.2 for armv7l. I'd accept such a PR today.