There is a code generation bug in Cabal-3.6.3.0. For packages configured with
--enable-relocatable, Cabal would generate code that doesn't compile.
There isn't an upstream issue, but the issue is described in the commit that
fixed it:
6c796218c9
It was fixed in Cabal-3.8.*
Backport the fix to the Cabal library that ships with ghc-9.2.4
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
Closes#200063.
Initial port of our GHC Nix expressions to the new hadrian build system,
as it has become required after 9.4. Unfortunately there are some
regressions affecting us, namely the inability to install a GHC
cross-compiler at the moment (see issue linked in relevant error
message). This means that a lot of specific configuration snippets for
cross-platforms and static compilation have been ported from make
speculatively, as we are unable to test them for the moment.
This shortens the bootstrap chain for 9.4.1 and should be kinder on
rebuilds. It requires some messing around in the configure file, since
it is not officially supported by upstream (but known to work). For now
it saves us the hassle of adding another bindist to nixpkgs. When we
support hadrian, we'll be able to use the already packaged 9.2.2
bindist.
Since the musl / alpine bindist now uses the GMP backend, we need to
learn to tell Hadrian bindists about GMP. Hadrian bindists no longer
have the buildinfo files, instead we need to patch the package db before
installing and recache it afterwards which is not too hard, luckily.
Same goes for libiconv and base as well as libffi and rts on
darwin (those bindists are all produced using hadrian).
See also: https://gitlab.haskell.org/ghc/ghc/-/issues/21554#note_431000
Note that pkgsMusl.haskell.compiler.ghc922Binary still has severe
issues: It can't produce shared libraries because the bindist ships
none (and using the GMP backend has a hard requirement for shared
objects, apparently) and ghci segfaults for unknown reasons at the
moment. However, I've successfully compiled hadrian with it so far, so
perhaps it's good enough.
This was disabled basically by accident before.
The links are jacked, but that was is true for every package; it is not
unique to this PR. I fixed it upstream here:
https://github.com/haskell/haddock/pull/1482
but it's not in any release distributions yet I don't think.
Fixes#171841
Otherwise attempt to build ghcHEAD from local checkout fails as:
$ nix build -L --impure --expr 'with import ~/nm {}; haskell.compiler.ghcHEAD.overrideAttrs (oa: { src = ./.; patches = []; nativeBuildInputs = oa.nativeBuildInputs ++ [ git ]; })' --keep-failed
...
ghc> checking C++ standard library flavour... ./configure: line 11487: /nix/store/r7r10qvsqlnvbzjkjinvscjlahqbxifl-gcc-wrapper-11.3.0/bin/cxx: No such file or directory
I think 'cxx' is not provided by stdenv.
Very confusingly, the `isPowerPC` predicate in
`lib/systems/inspect.nix` does *not* match `powerpc64le`!
This is because `isPowerPC` is defined as
isPowerPC = { cpu = cpuTypes.powerpc; };
Where `cpuTypes.powerpc` is:
{ bits = 32; significantByte = bigEndian; family = "power"; };
This means that the `isPowerPC` predicate actually only matches the
subset of machines marketed under this name which happen to be 32-bit
and running in big-endian mode which is equivalent to:
with stdenv.hostPlatform; isPower && isBigEndian && is32bit
This seems like a sharp edge that people could easily cut themselves
on. In fact, that has already happened: in
`linux/kernel/common-config.nix` there is a test which will always
fail:
(stdenv.hostPlatform.isPowerPC && stdenv.hostPlatform.is64bit)
A more subtle case of the strict isPowerPC being used instead of the
moreg general isPower accidentally are the GHC expressions:
Update pkgs/development/compilers/ghc/8.10.7.nix
Update pkgs/development/compilers/ghc/8.8.4.nix
Update pkgs/development/compilers/ghc/9.2.2.nix
Update pkgs/development/compilers/ghc/9.0.2.nix
Update pkgs/development/compilers/ghc/head.nix
Since the remaining legitimate use sites of isPowerPC are so few, remove
the isPowerPC predicate completely. The alternative expression above is
noted in the release notes as an alternative.
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
At some point in hadrian's installation Makefile used for e.g. alpine
bindists 'xxx' is used as a placeholder for three spaces and later
substituted back. This breaks if the store path itself contains 'xxx'.
We adapt an upstream patch which will be part of 9.4 (and presumably
9.0.3 and 9.2.3) as a workaround for this issue for 8.10.2 and 8.10.7
which are the binary GHCs in nixpkgs affected.
The issue we are working around is concerned with the lack of dead
code elimination in the aarch64-darwin LLVM codegen backend. Thus
the relevant condition is the target platform, not the host
platform as checked previously.
The condition used in the past to detect iOS was "is this
aarch64-darwin"? Since we have aarch64-darwin devices running macOS
nowadays which do allow large address space, let's use the more accurate
flag.
enableDwarf requires elfutils on the host, which doesn't support darwin.
Instead of hardcoded isDarwin/isWindows, switch to self-documenting
availableOn conditional for elfutils.
Fixes ghcHEAD cross-compilation when build = host = darwin,
target = linux.
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
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.
Since 4c75874560 it is possible to
introspect if ld.gold is contained in the used bintools, so we can also
check if it is available before deciding to use it as done in the other
GHC derivations in 0908812372.
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.
This brings the binary GHCs on parity with the source built ones in
terms of the wrapper. The upshot of this is that compiling something
using the binary GHCs no longer depends on PATH being populated with
the tools included in stdenv at all. We can even test this by running
the installCheck with an empty environment (via `env -i`).
Copy the approach from the normal GHC derivations for adding an
`export PATH` into the scripts in `$out/bin` and use it to put the
specific LLVM version of the binary GHC into its PATH. This will
prevent the LLVM version of the GHC we are building later to take
precedence over the LLVM version this GHC needs.
Since we inherit the platform list from the bootstrap GHC, we get
differing lists depending on which platform we evaluate the platform
list on (depending on whether 8.10.2 or 8.6.5 is used). This leads to
Hydra thinking aarch64-linux is not supported as it evaluates on
x86_64-linux usually.
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 means we only have to update the llvmPackages attribute in one
place now and should prevent situations like with 8.6.5 where different
versions would be used in the package set compared to the compiler
build.
Drop comments in the configuration-ghc-X.Y.x.nix files as well, since
LLVM version isn't tied to the compiler minor version at
all (e. g. 8.10.2 and 8.10.7 have different support ranges).
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
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>
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
* ghcHEAD: bump to 8.11.20200403
* ghcHead: reduce diff vs. 8.10.1
dontAddExtraLibs was removed by accident (IMO) in ea19a8ed1e
* ghcHEAD: add ability to use system libffi
- enable nixpkgs' libffi
- minimise diffs against 8.10.1
- remove patching
* remove configure warning about --with-curses-includes
configure: WARNING: unrecognized options: --with-curses-includes
