The common expression is a little messy to avoid rebuilds. It can be
cleaned up in a second step.
`9.4.8.fixme.nix` is used temporarily so that git's rename detection
gets where common-make-native-bignum.nix is coming from.
8.10.7 keeps its expression since it uses integer-simple which changes
the expression's interface. This is unfortunately very annoying to
reflect in a common expression.
This disables building dynamic libraries for GHC 9.4.x and before, when enableShared and
enableProfiledLibs are set to false. Currently this only disables dynamic linking of GHC
itself, but still creates dynamic libraries.
The hadrian-based GHC 9.6+ already disable building dynamic libraries via the no_dynamic_libs
transformer in this case.
The reason for this happening before was, that the default was assumed to be "v p dyn", of
which "p" was taken away when profiled libs were disabled. But this would unconditionally
enable the dyn way. Using the BUILD_PROF_LIBS flag in this case will let GHC's config.mk.in
script make the proper decisions about which GhcLibWays to build.
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.
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>
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 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.
