GHC HQ switched the musl bindists from gmp to `integer-simple`
with GHC >= 8.10.6, but this was not reflected in the nixpkgs update:
* commit 6f1242469a: ghc: 8.10.5-binary -> 8.10.7-binary
From PR #135453
See also #130441.
Conflicts:
pkgs/development/compilers/ghc/8.10.7.nix
pkgs/development/compilers/ghc/8.8.4.nix
I've removed the isWindows check from useLdGold in ghc, since that should
be covered by the new hasGold check.
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.
Seems like there is either a fundamental issue with how our derivation
works or an upstream bug prevent GHC 9.2.1 from compiling on macOS using
nixpkgs. Until someone fixes that or rc2 comes around, we can save the
build time.
GHC 8.8.4 seems to be quite susceptible to flaky build failures when
using more cores. Since we don't care about speed too much with this
one, let's disable big-parallel again.
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.
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.
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>
Building `haskell.compiler.ghcHEAD` on Hydra on Darwin seemed to cause
frequent timeouts.
Here's an example of a timeout: https://hydra.nixos.org/build/149762652
This commit raises the timeout time on Hydra for ghcHEAD. The other
GHC derivations have this set, so it makes sense to set this here
as well.
The musl support for binary GHC 8.6.5 relied on ABI compat between musl
and glibc which is no longer the case: https://github.com/NixOS/nixpkgs/issues/129247
Since there is no upstream musl (alpine) bindist for GHC 8.6.5, we can
only accept that binary 8.6.5 is not possible with musl.
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.
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; }'
This commit replaces the musl + glibc hackery in the GHC bindist
compiler by using the new musl based bindist that GHC HQ provides
(built on Alpine).
We could alternatively also use a nix-built musl boostrap compiler,
but it seems nicer to use the GHC HQ one for now.
This fixes the compiler built by
`pkgsMusl.haskell.compiler.ghc8102Binary` segfaulting (#118731)
since the commit
5e2311d2f - musl: 1.2.1 -> 1.2.2
concretely, musl commit
01c7920f - remove redundant pthread struct members repeated for layout purposes
which I suspect breaks some glibc/musl ABI compatibility that may have
existed accidentally until then.
The added
lib.optional stdenv.targetPlatform.isMusl "pie";
also fixes that the packaged bindist compiler cannot create a binary
in its `installCheck` phase (and overall); see detail explanation
in #129247.
With this check, we no longer don't notice when the upstream bindist
changes its dependencies (e.g. because a newer Debian version is used
that uses a new `ncurses` version).
The library override that was present in the code referred to a
name that isn't even used in current GHC bindists.
Tested with:
NIX_PATH=nixpkgs=. nix-build --no-link -A haskell.compiler.ghc8102Binary --argstr system i686-linux
With sphinx 4, interpreting the conf.py fails due to a decode
error: https://gitlab.haskell.org/ghc/ghc/-/issues/19962
The fix is an one line change which we have to backport from GHC
master.
9.2 and 8.10.6 will have a fix for this, GHC 9.0.1 and ghcHEAD
already have and GHC 8.10.4 has been patched in nixpkgs already.
With sphinx 4, interpreting the conf.py fails due to a decode
error: https://gitlab.haskell.org/ghc/ghc/-/issues/19962
The fix is an one line change which we have to backport from GHC master.
Thus ghcHEAD is not affected by this problem.
9.2 and 8.10.6 will most likely have a fix for this.
TODO: Patch 8.8.4 and 9.0.1
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.
The broken build of ghcHEAD on aarch64-linux results from rts/Libdw.c
not supporting that platform. Seemingly this particular file is only
relevant for DWARF support in GHC, so we disable that on unsupported
platforms.
The tarball download URLs seem to have changed, so we adjust them in
case anyone wants to reproduce the source of ghc8102Binary and
ghc865Binary.
Tested for x86_64-linux, i686-linux, aarch64-linux, x86_64-darwin.
Resolves#121804.
Previously, the "ar command" in the global config of GHC in nixpkgs is
simply "ar" instead of a proper absolute path in the nix store. This
will result in an "ar: command not found" error when using GHC and cabal
in a pure nix shell. This commit adds the patch and applies to all
pre-9.0 versions.
See output of ghc --info for "ar command" value.
x86_64-linux
Ben Gamari's patch from #85924.
Fixes#85924, allowing one to bootstrap GHC in `pkgsMusl`
`nix-build -A pkgsMusl.haskellPackages.hello` succeeds with this patch.
Please do not use tarballs.nixos.org in src URLs. tarballs.nixos.org is
a cache, not an authority.
This patch differs from the one in tarballs.nixos.org only in source code
comments.
Fixes:
utils/ghc-cabal/dist-install/build/tmp/ghc-cabal:
error while loading shared libraries: libnuma.so.1:
cannot open shared object file: No such file or directory
