By specifying pkgs.libffi here instead of letting callPackage handle
it, we confuse the splicing logic and put the host libffi into
NIX_LDFLAGS_FOR_TARGET. This previously hasn't been a problem, as we
also pass an explicit configure flag pointing to the target libffi,
and so the only side-effect is a senseless -rpath flag.
ld.lld (rightly) does not recognize the -rpath flag when targeting
Windows, however, so this causes build failures.
On non-arm platforms there's no reason to use the minimal GHC for musl
bootstrapping, as it doesn't hit the size limit. Additionally this serves
as a wonky workaround for ghc#21402 [1], as the minimal GHC 8.10.2
binary currently contains `xxx` in its `outPath`.
[1]: https://gitlab.haskell.org/ghc/ghc/-/issues/21402
It appears that integer-gmp is already set to null for all compilers,
so there is no need to explicitly set it to null in the integer-simple
and native-bignum package sets.
Currently, the build on MacOS ARM64 is broken because LLVM 9 (or more
specifically compiler-rt) is broken (and is marked broken). Both
8.10.7 and 9.2.1 are already set to LLVM 12 so this PR adjusts this to
also use LLVM 12 for GHC 9.0.2 which seems to get things building for me.
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).
This should shorten the bootstrapping part (not requiring an
intermediate 9.0.1 build). Seems like 8.10.7 is still supported for
bootstrapping for the moment and allows compiling for aarch64-darwin.
Reverse bootstrapping is not supported by GHC upstream. In the case of
8.8.4 it just happens to work using 8.10.2, with later versions,
specifically 8.10.7 there seems to be some digressions in the generated /
used C code which cause 8.8.4 to fail to compile [1].
Thus we revert to using 8.10.2 for aarch64 and Musl which means: Still
no integer-simple and musl at the same time (however all other GHCs have
it, so it's probably not a problem) and no aarch64-darwin (GHC 8.8.4
can't target that architecture anyways). In short, the situation stays
the same.
[1]: https://github.com/NixOS/nixpkgs/pull/138523#issuecomment-927339953
GHC 9.2.1-rc1 needs to run xattr in ghc.mk unconditionally. The fix for
this and support for the XATTR environment variable have only been added
to the GHC 8.10 series so far.
The only big change is required for darwin since GHC 8.10.5 now
runs xattr in the install phase on darwin:
* 11e1dcde0d
* ec451cac39
Unfortunately, it uses the host /usr/bin/xattr by default which is
present in the build due to a lack of sandboxing on darwin. That xattr
version however still requires Python 2.7 whereas Python 3.8 is in PATH
in our build. We solve this by setting the XATTR environment variable.
We can't use python3Packages.xattr since GHC expects Apple's fork of
xattr which provides some extra flags to utilize.
Co-authored-by: Cheng Shao <cheng.shao@tweag.io>
This reverts commit 36628e6e04.
As it turns out this wasn't caused by the update from python 3.8 -> 3.9,
but the underlying issue affects both python version (it seems that LTO
is at fault currently). Will have to be fixed elsewhere, reverting.
seems like python39 currently fails to build with musl as libc
https://github.com/NixOS/nixpkgs/issues/131557. As a workaround, we can just
build the musl GHCs using python38 like we have been in the past (the python 3.8
-> 3.9 update being a more recent development).
This addresses the fact that `ghc865Binary` segfaults on musl
(see #118731) because of the glibc+musl mix used in there.
With the previous commits, `ghc8102Binary` was changed to use
the musl-based bindist from GHC HQ instead, which works.
With this change, all nix Haskell compilers builds on musl:
NIX_PATH=nixpkgs=. nix-build --no-link --expr 'with import <nixpkgs> {}; { inherit (pkgsMusl.haskell.compiler) ghc884 ghc8104 ghc901 ghcHEAD; }'
ghc8102Binary doesn't build on hydra on arm since it exceeds the maximum
output size. This change works around this issue by using the minimal
version of that compiler instead.
Shea Levy