Verified that there are no hash changes (eval platform x86_64-linux) in:
- haskell.compiler
- pkgsCross.armv7l-hf-multiplatform.haskell.compiler
- pkgsCross.armv7l-hf-multiplatform.buildPackages.haskell.compiler
Our theory is that only sphinx and haddock need a working locale on
the build platform. We should actually put this into practice so our
understanding matches our build instructions.
The commit adding LOCALE_ARCHIVE, 8a21e02e31, cites haddock
generation which happens during the build and on the build platform.
As it turns out, the user guide also depends on locales because
sphinx tries to set a locale during execution.
This should fix cross compiling ghc from glibc to non glibc, e.g.
x86_64-pc-linux-gnu -> aarch64-unknown-linux-musl
Since cross compilers can also build code for the build platform, we
should also install these debug scripts so they are available just like
in our non-cross rustc.
Implement a wrapper script to translate the `opt(1)` arguments passed
by the GHC 9.0.2 binary distribution to the equivalent arguments
for the new LLVM pass manager passed by GHC ≥ 9.10 and our
soon‐to‐be‐patched compilers. This ensures that the bootstrap
of GHC 9.4 continues to work on AArch64.
On an earlier version of this change, I built `haskell.compiler.ghc948`
on both `aarch64-linux` and `aarch64-darwin`, and
`haskell.compiler.ghc924` on `aarch64-linux` only (it is already
broken on Darwin). I confirmed that we get functionally identical
store outputs before and after this change, modulo self‐references:
$ cp -a result-before/ before
$ cp -a result-after/ after
$ chmod -R +w before after
$ LANG=C find before -type f -exec \
remove-references-to \
-t $(readlink result-before) \
-t $(readlink result-before-doc) \
'{}' ';'
$ LANG=C find after -type f -exec \
remove-references-to \
-t $(readlink result-after) \
-t $(readlink result-after-doc) \
'{}' ';'
# Darwin only: normalize build user UIDs in the archive files…
$ LANG=C find before -name '*.a' -exec \
sed -i 's/ 360 / 351 /g' '{}' ';'
$ diff -r before after
# Linux only: the `package.cache` files differ, presumably due to
# an unrelated reproducibility issue.
Therefore, bumping this LLVM dependency did not affect the end result
of the bootstrap for the only compilers it is used for.
These binary packages are available for a fixed set of platforms,
all of which support the native code generator. Therefore, the
`llvmPackages` argument was never used. We leave an assertion around,
just in case.
Also, rearrange the GHC‐related release notes to be in order of
most likely to matter to anyone.
Co-authored-by: Wolfgang Walther <walther@technowledgy.de>
