The reasoning given for disabling it is flawed: In most cases, sphinx
and its dependencies are already in the binary cache, since we only need
them as build tools—sphinx for the build platform is just the normal
pkgs.sphinx, since it doesn't care about targetPlatform.
We just need to disable it when the buildPlatform is also musl, so we
avoid pulling in sphinx in pkgsMusl.
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
In this situation, haddock would not be built by hadrian, as there is no
stage0:exe:haddock target by default. (We should eventually try adding
one.) If haddock is enabled and the build->host haddock missing, Cabal
tries using the build->build haddock which may fail to load the
documentation from the interface files produced by the build->host
GHC (e.g. due to a mismatch between dynamic and static linking).
Add regression tests to haskell-updates jobset.
Resolves#275304.
This ports our infamous patch for `Cabal` which cheesily prevents an
output cycle for derivations that use separate bin outputs where
references caused by the `Paths_*` module can't be eliminated by the GHC
aarch64-darwin codegen backend.
See also
- the original issue #140774,
- the original patch for GHC 9.2 #216857
- the ported patch for GHC 9.4
f6f780f129
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
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.
GHC has a native backend for POWER and SPARC. This is relevant to 8.6.5
binary in the case of POWER where we actually have a bindist and don't
need to include LLVM.
GHC 8.6.5 binary is essentially broken on aarch64-linux, hence the
platform has been removed from meta in the past. We can also drop the
corresponding src data to lessen confusion.
When 9.2.1 was [released], I apparently was confused by the wording. The
NCG (-fasm) codegen backend for aarch64 not only works on
aarch64-darwin, but also aarch64-linux. `useLLVM` being enabled on
aarch64-linux had no adverse effect, as GHC used -fasm anyways, but it
did inflate closure size unnecessarily which we can rectify now.
[released]: https://www.haskell.org/ghc/blog/20211029-ghc-9.2.1-released.html
This was already applied to GHC 9.2.x, but was not copied to GHC 9.4.x.
I have had issues with this locally.
The same patch works for both Cabal 3.6 and 3.8, so we can just reuse it.
The `meta` set of the binary GHCs is mostly independent of the used
bindist (except for `pname` which includes `variantSuffix`). Thus we
should make sure it can be evaluated even if no bindist is available for
the platform, i.e. evaluating `outPath` may cause an evaluation failure,
but `meta.platforms` not. Use case at present is to make
`lib.meta.availableOn` work everywhere for any GHC (the normal GHCs
inherit their platforms list from their respective boot compiler, at
least for now).
To fix this we need to make sure that shallowly evaluating `passthru`
doesn't force `binDistUsed`, since `mkDerivation` needs to merge
`passthru` into the resulting derivation attribute set, thus forcing the
attribute names of `passthru`. We can easily do this by accessing what
we want to learn from `ghcBinDists` manually and using `or` to fall back
to a sensible default.
The switch to cctools-llvm made several LLVM tools the default on
Darwin, which includes llvm-ar. GHC will try to use `-L` with `ar` when
it is `llvm-ar`, but that doesn’t work currently on Darwin.
See https://gitlab.haskell.org/ghc/ghc/-/issues/23188.
This saves just enough space on aarch64-linux so that the hadrian built
GHCs are under the 3GB Hydra output limit:
| compiler | before | after | Δ |
|----------|------------|------------|------------|
| ghc962 | 3241234736 | 2810740560 | -430494176 |
| ghcHEAD | 3341288328 | 2902760872 | -438527456 |
The total output size can be calculated using (don't forget to use
aarch64-linux):
```
nix-build -A <compiler> | xargs nix path-info -s | awk '{ s += $2 }; END { print s }'
```
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.
The main problem was GHC exceeding the Hydra output limit with profiling
libs on aarch64-linux which made us disable the feature. Nowadays the
limit is 3GB, the GHC output is a bit over 2GB, so easily under the
limit.
aarch64-darwin uses a different codegen backend and was never really
affected by the problem: Its output with profiling enabled is around
1.6GB.
Consequently we can enable profiling for all platforms again, as we have
no output size issues for those we build on Hydra.
Thanks to flokli for helping me track down these up to date numbers.
Hadrian (the GHC build tool) is built separately from GHC. This means
that if `haskell.compiler.ghc961` is overridden to add patches, those
patches will _only_ be applied to the GHC portion of the build, and not
the Hadrian build. For example, backporting this patch to GHC 9.6.1
failed because the changes to `hadrian/` files were not reflected in the
Nix build:
5ed77deb1b
By lifting `src` and `hadrian` from variables defined in the function
body to parameters with default values, the `hadrian/` files can be
overridden using the `haskell.compiler.ghc961.override` function. For
example:
self.haskell.compiler.ghc961.override {
# The GHC 9.6 builder in nixpkgs first builds hadrian with the
# source tree provided here and then uses the built hadrian to
# build the rest of GHC. We need to make sure our patches get
# included in this `src`, then, rather than modifying the tree in
# the `patchPhase` or `postPatch` of the outer builder.
src = self.applyPatches {
src = let
version = "9.6.1";
in
self.fetchurl {
url = "https://downloads.haskell.org/ghc/${version}/ghc-${version}-src.tar.xz";
sha256 = "fe5ac909cb8bb087e235de97fa63aff47a8ae650efaa37a2140f4780e21f34cb";
};
patches = [
# Enable response files for linker if supported
(self.fetchpatch {
url = "5ed77deb1b.patch";
hash = "sha256-dvenK+EPTZJYXnyfKPdkvLp+zeUmsY9YrWpcGCzYStM=";
})
];
};
}
Note that we do have to re-declare the `src` we want, but I'm not sure
of a good way to avoid this while also sharing one set of patches
between the GHC and Hadrian builds.
We previously thought that we only need python if we were going to run
./boot or using emscripten which implements all its wrappers in
python (and likes to reinvoke them). As it turns out, though, hadrian
likes to invoke python itself for generating certain headers of rts
using a script shipped with the GHC source. This fact was obscured
before, since (presumably) sphinx would propagate python into PATH.
