Unfortunately, we are running into trouble linking dependencies of
hadrian against the libraries of the clock package with 9.6.3 and
9.6.4 _bindists_. My current suspiscion is that this is caused by
some kind of discrepancy between the toolchain used by GHC upstream
and us that persists from the configure step used when building the
bindist. The problem seems to be somewhat localized to hsc2hs (hence
clock is an issue), with GHC 9.6.4 bindists even passing a flag to
ld that is not supported by our version of cctools.
The problem is not fully diagnosed, so take the speculation above
with a grain of salt.
As a workaround, we can use the source built GHC 9.6 which is, of
course, configured with our toolchain in the environment.
Bootsrapping with 9.6 doesn't work with 9.8.2 upstream due to erroneous
bounds on Cabal (<https://gitlab.haskell.org/ghc/ghc/-/issues/24100>)
which was planned to be addressed in 9.8.2, but apparently hasn't been,
so we need to extend the range for the workaround patch.
native-bignum has become the norm, so let's convert it to an exclude
rather than an include list. This way it's no longer possible to forget
to add a newly packaged GHC to the include list.
Best reviewed by viewing
diff -u pkgs/development/compilers/ghc/9.{2.4,6.3}-binary.nix
main change are that we drop the `isHadrian` mechanism, since all
bindists are produced by hadrian and alpine bindists are also available
dynamically linked now.
https://www.stackage.org/ lists the latest LTS snapshot for any GHC
version which, on the flipside, lets us discover which versions don't
have a corresponding LTS snapshot. There is really no reason to keep
around GHCs that only appeared in some nightly snapshot way back.
haskell.compiler.ghc924: remove at 9.2.4
haskell.compiler.ghc942: remove at 9.4.2
haskell.compiler.ghc943: remove at 9.4.3
haskell.compiler.ghc944: remove at 9.4.4
haskell.compiler.ghc962: remove at 9.6.2
We want to remove llvmPackages_6, but it is the only version GHC 8.6.5
supports. Luckily, we actually don't need LLVM in any case, since all
X86 architectures have native codegen for Darwin and Linux, as well as
POWER for Linux. Consequently, we can just pass `null` and add an extra
assert to make this more transparent to future tinkerers.
There won't be any new integer-simple compilers and they are already in
the minority, so converting the mechanism to an include list is much
better. Maybe native-bignum should now become an exclude list
additionally?
Verified that nix-env -qaP -A haskell.compiler output stays identical.
haskell.compiler.ghc8102BinaryMinimal: remove at 8.10.2
haskell.compiler.ghc8107BinaryMinimal: remove at 8.10.7
haskell.compiler.ghc924BinaryMinimal: remove at 9.2.4
On aarch64-linux the binary GHCs take up about 2.6GB (which compresses
pretty well on zfs as it turns out), so they are below the output limit
of Hydra. This allows us to drop the special casing of aarch platforms
in haskell-packages.nix. While we're at it, drop the minimal variants so
we don't unnecessarily build variants of the binary GHCs.
This should make overriding the precisely versioned set also influence
the default aliases. When overriding the aliases, still only the aliases
would be changed.
GHC HEAD is a pre basically pre GHC 9.8 (or rather 9.7 something).
Let's name the configuration like the upcoming release, so we can use it
immediately when the new release comes out. Instead of keeping the HEAD
configuration like we used to, we'd create a new (empty) one.
Initial port of our GHC Nix expressions to the new hadrian build system,
as it has become required after 9.4. Unfortunately there are some
regressions affecting us, namely the inability to install a GHC
cross-compiler at the moment (see issue linked in relevant error
message). This means that a lot of specific configuration snippets for
cross-platforms and static compilation have been ported from make
speculatively, as we are unable to test them for the moment.
