Some GHC bindists have a normal `$out/lib` directory which contains
symlinks to all core libs. Because it is a normal lib directory, the
bintools setup hook will pick up on it and cause ld to pass the
appropriate -L and -rpath flags. We do not want this to happen,
especially in the case of the stage2 compiler. Not only will the final
ghc have an unnecessary reference (and thus increased closure size) to
the binary ghc, but the extra libraries in the rpath mess with the rts
and cause e.g. segfaults in GHCi.
Unfortunately, there is no way to prevent this. It is a fundamental flaw
in the cc and bintools wrappers that they do not actually distinguish
between the roles of dependencies (build, host, target). Instead
the mangleVar* function will translate the dependencies split up by
roles into platforms. This means that the wrappers can't distinguish
between depsBuildBuild and depsHostTarget (== buildInputs) when natively
compiling. As long as we are natively compiling the wrappers will put
the stage0 ghc (be it in depsBuildBuild, nativeBuildInputs etc.) into
the linker flags of the final ghc.
The solution is to sidestep the issue. We just had ghc in depsBuildBuild
to have it added to PATH. GHC itself will pass the appropriate linker
flags if necessary. To avoid the setup hooks picking up on the GHC
libraries we just don't put it into depsBuildBuild or any other
dependency list. Since the GHC build system accepts the GHC binary via
an absolute path, we don't even need to add the stage0 GHC to PATH.
The stage0 ghc is build->build since it builds the stage1 compiler which
has build for its host platform (i.e. is build->target relative to the
entire GHC derivation).
Also annotate a bit more around the use of pkgsBuildBuild and the boot
compiler and make it more explicit where it comes from in the
derivation.
In #339272, an elusive regression was found where the stage 2 binaries
held a reference to the boot compiler in their rpath. This issue only
affected GHC 9.6 versions built on aarch64-linux.
For still unknown reason, this issue goes away when using a source built
GHC instead of the binary GHC we derive from upstream's bindists.
Knowing more would be great, obviously, but at least this issue goes
away with GHC 9.8.*…
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
This is a left over to do from #308776. Rebasing existing PR (prior
to #308776) would need to be rebased on a change before the commit
included in this PR.
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.
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.
