This is no substantial change, as we already assert that the
build->target and host->target LLVM are the same, but this brings the
terminology in the file in a more consistent order, since we use
build->target for CC/CXX and bintools already.
In fact we should be passing build->target to configure always,
host->target would come into play when updating GHC's settings file
after installing.
On aarch64-darwin we have additional wrappers for install_name_tool and
strip to deal with codesigning requirements (e. g. updating the
signature / checksum after changing a binary). These wrappers don't
exist on x86_64-darwin which is why the unwrapped versions were used
before, causing the kernel to kill (some) executables produced by GHC.
CC, CXX, LD, AR, …, LLC, OPT and CLANG will be invoked by GHC's build
system at build time in the build->target role. However, since we are
passing absolute paths, they will get saved in GHC's settings file and
later invoked at runtime, when they should be host->target. This means
that the build->target and host->target tools need to be the same for
our built GHC to work properly which is what we guard using these new
asserts.
Being able to drop these asserts would be a step towards cross-compiling
GHC (as opposed to building a GHC cross-compiler which still works).
* By taking clang from llvmPackages we make sure there is no version
mismatch between LLVM (where llc and opt come from) and clang (which
previously would be taken from stdenv on darwin for example).
* Only pass CLANG if useLLVM is true. Previously we also set this if
targetCC was clang. This would cause potentially confusing behavior if
llc and opt as well as clang are provided via PATH (and GHC is
compiled with useLLVM == false), because clang from PATH would be
ignored, but not llc and opt.
These targets also have NCG support, but they are tested less (in fact
SPARC seems to be untested atm) and may have issues. In such cases being
able to fallback to -fllvm without rebuilding the compiler could be
useful. OTOH GHC will default to -fasm and the backends probably work
well enough in most cases.
GHC can actually accept absolute paths for its runtime tools (except for
touch) at configure time which are then saved in
`$out/lib/ghc-${version}/settings`. This allows us to drop the wrapper
entirely if we assume that a POSIX compliant touch is in PATH when we
run GHC later.
The touch problem can presumably be fixed by either patching the
configure file of GHC (although we need to take care not to change the
touch GHC uses during its compilation) or messing with the settings file
after installation.
The rationale for dropping the wrapper PATH entry completely is that
it's always possible to invoke GHC via its library which will bypass the
wrapper completely, leading to subtly different behavior.
Binary GHCs are not touched in this commit, but ideally they'll get a
similar treatment as well, so they are more robust, although we
generally don't need to use them as a library.
Note that GHC 8.8.4 doesn't care about install_name_tool or otool, so
the respective environment variables are not set.
This has two main benefits:
* GHC will work reliably outside of stdenv, even when using -fllvm since
everything it'll call at runtime will be provided in PATH via the
wrapper scripts.
* LLVM will no longer leak into haskell packages' configure
scripts. This was an issue with llvm-hs which fails to build if the
LLVM version of the compiler since the propagatedBuildInputs of GHC
take precedence over the nativeBuildInputs added in the derivation.
Since LLVM itself doesn't depend on target at all, this doesn't change
anything *in effect* (i. e. rebuild count should be zero), but it is
more clear about the intention and what LLVM is used for here (i. e. in
depsBuildTarget).
When debugging musl builds, I often have to sift through thousands of lines
of `nix-store -q --tree` or `nix-store -qR` output.
Until now, `pkgsMusl` and normal `pkgs` GHCs looked exactly the same in
there, making that task tough.
Same for `integer-simple`, which makes debugging `gmp` issues easier.
This commit introduces a suffix to tell them apart easily.
Note that this is different from `targetPrefix` which is for
cross-compilation, which `pkgsMusl` does not do.
For GHC HEAD, integer-simple no longer exists, instead we now have a
“bignum backend”, so we just call the integer-simple successor
native-bignum.
Co-Authored-By: sternenseemann <sternenseemann@systemli.org>
Let's remove peti (retired) as well Marc, Andres and Will who haven't
been active lately. Feel free to re-add yourself, but this should at
least lessen the GitHub notifications for now.
Add lib.teams.haskell to every maintainer list additionally. I've also
added Domen and Pavol to GHC 8.10.7 binary since they are the only ones
working on aarch64-darwin so far. Let me know if that is alright with
you.
Compiling GHC on Hydra takes 3h or more (with -j2) whereas even on an
outdated CPU GHC can be compiled in under an hour with -j4. To get a
higher NIX_BUILD_CORES value at build time, we'll have to mark GHC
big-parallel.
Adds new package options:
* enableDocs
* enableHaddockProgram
to control whether to build Sphinx docs, and GHC haddocks and the
haddock program.
Unfortunately currently the building of the `haddock `program
and generating GHC docs are mixed into one option, see:
https://gitlab.haskell.org/ghc/ghc/-/issues/20077
Making Sphinx docs disableable, and disabling them by default
for Musl and cross builds, makes it much easier to provide these
builds without having to support Sphinx's enormous dependency
tree for those ways of building.
useLdGold previously just checked for useLLVM which (currently) implies
`linker == "lld"`. However more accurate is to check the `linker` of the
`targetPlatform` as it actually tells us which bintools package we can
expect.
`linker == "bfd"` implies that we are using the `binutils` package, so
gold is available, so we can use it unless musl is the libc. `linker ==
"gold"` implies that gold is the default linker already and we should
absolutely use it.
GHC calls otool on darwin which is contained in the
stdenv.cc.bintools.bintools derivation and thus needs adding to the
runtime PATH of GHC. Since this is toolchain specific technically, we
check for cctools instead of darwin (although I don't know if GHC
or nixpkgs work on macOS without cctools).
This fixes usage of GHC in an environment where otool is not available
and more specifically in stdenvNoCC which is used by writers.writeHaskell.
Resolves#123228.
