This makes isNativeBignumGhc purely textual again after #460845.
Could improve performance in the right conditions, but most importantly
solves eval issues with aliases allowed (due to the throw-ing ghc
attributes) without resorting to tryEval.
Latest 9.12.x minor release is 9.12.4, which is also in Stackage Nightly
already, so will never be the latest in a Stackage major version.
Thus, dropping according to the GHC Deprecation Policy.
The package set is built entirely from source using the stdenv and Hugs.
This also replaces the recently added microhs package, which was built
from pre-generated compiler output.
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
After #490755, the problematic regression has been patched, so we can actually
update. After the fixes for fourmolu and cabal-add, HLS can also be built with
GHC 9.12.3.
LLVM 12–17 have been dropped for Nixpkgs 25.11. As discussed recently
on Matrix, this backports upstream changes to allow the use of
LLVM 20 for all GHC versions from 9.4.8 onward.
I looked over GHC commits mentioning LLVM since the release of 9.4.8,
and read the discussions and issues around the relevant bumps, and
attempted to be quite thorough, but I obviously cannot guarantee that
this is wholly comprehensive. It seems like upstream generally bumps
the upper bound on the basis of “it builds successfully for me”,
with specific adaptations for new versions being fairly uncommon and
only coming for obvious build blockers or reactively in response to
bug reports. I have backported both kinds of changes here.
For some commits, trivial conflict resolutions and adaptations
were required. It would be possible to pass the affected files to
`fetchpatch` as `excludes` and keep smaller fix‐up patches in tree in
some cases, but I opted to keep it simple and vendor complete backport
patches instead. I did not attempt to backport every single change to
the LLVM backend, only those that seemed directly relevant to support
for newer versions; if you’d get the same issue with the older LLVM,
that’s just a GHC bug.
These changes should actually make it easier to cross‐compile for
new architectures, as more recent LLVMs will have better support for
newer platforms, and it will be easier to backport GHC changes to
enable new platforms with less drift in the backend.
These patches do result in two breaking changes. Firstly, the minimum
LLVM version is bumped to 13 across the board. This is irrelevant for
Nixpkgs as we pin a specific LLVM version anyway, and versions below
LLVM 18 will be removed imminently. Secondly, support for the hidden
`-fno-llvm-tbaa` flag is dropped. This can be replaced with custom
`-optlo` flags to control the passes more directly, but the main
use of this undocumented flag appears to have been to [work around]
the lack of support for newer LLVM versions, anyway.
[work around]: <https://gitlab.haskell.org/ghc/ghc/-/issues/22220>
I successfully built the following on `aarch64-linux`:
* `pkgsCross.armv7l-hf-multiplatform.buildPackages.haskell.compiler.ghc948`
* `pkgsCross.armv7l-hf-multiplatform.buildPackages.haskell.compiler.ghc967`
* `pkgsCross.armv7l-hf-multiplatform.buildPackages.haskell.compiler.ghc984`
* `pkgsCross.armv7l-hf-multiplatform.buildPackages.haskell.compiler.ghc9102`
* `pkgsCross.armv7l-hf-multiplatform.buildPackages.haskell.compiler.ghc9121`
* `pkgsCross.armv7l-hf-multiplatform.buildPackages.haskell.compiler.ghc9122`
* `pkgsCross.riscv64.haskell.compiler.ghc948`
The GHC 9.4.8 with an ARMv7 host platform segfaults when I try to run
GHC, though e.g. `ghc-pkg --help` runs successfully. The GHC 9.10.3
build targeting ARMv7 crashed inside `llc(1)`, so I tried RISC‐V,
which has some platform mismatch issue relating to `libffi`, so I
tried z/Architecture, which failed with an invalid floating point
constant in the LLVM IR, so I tried 64‐bit MIPS, which failed with
a different `libffi` issue, so I tried 32‐bit MIPS, which failed
to compile `compiler-rt`, so I gave up. I confirmed that both of the
ARMv7 issues reproduce with 944e8fd4f4,
the revision before they were bumped from their old versions of LLVM,
so these are not regressions.
I built a test program with the ARMv7 cross‐compilers and
confirmed that they run on the AArch64 builder. I also confirmed
that the cross‐compiled RISC‐V GHC successfully runs under
`qemu-riscv64(1)`. It will only try to build programs via the C
backend, though, as that is the only option for unregisterised™
targets, so it’s not clear to me how useful LLVM support in 9.4.8
really is for bootstrapping new platforms; I guess even RISC‐V
would require more backporting work to produce a cross‐compiled
GHC that will use LLVM to compile its own input. I didn’t bother
setting up all the binfmt machinery to get it through compiling and
running a test program, but it at least makes the attempt.
(cherry picked from commit b6be8a03a7)
We’d want every version to be able to trace back to 9.4.8 for the
“cross‐compiled GHC bootstrap tarballs” plan, anyway. I’m not
sure whether we’d want a `ghc948Binary` package that also includes
the official tarballs, or just only use our cross‐compiled binary
distributions, but it will make sense to align the version used for
bootstrap regardless.
(cherry picked from commit da915f81ef)
This bootstraps mostly from ghc984Binary, at least for the major
platforms. The bootstrap paths for darwin become much shorter.
Unfortunately, the bootstrap paths for i686-linux become a bit longer,
so it's a trade-off.
(cherry picked from commit 5df6c9a28f)
Latest 9.10.x minor release is 9.10.2, which is also in Stackage 24.8.
Thus, dropping according to the GHC Deprecation Policy.
(cherry picked from commit ac5228c6c0)
A lot of the links to issues in pkgs/development/compilers/ghc note
historical issues we need to workaround for outdated versions of GHC
or note related discussion. Them being closed is not actionable in many
cases so I have marked them with krank:ignore-line, so they don't show
up in reports generated using krank.
darwin.xattr used to be a fork of python3.pkgs.xattr.
bafc6ff88d switched darwin.xattr to Apple's new
C implementation of the tool.
When I originally packaged darwin.xattr (283d622397),
I linked tickets on the original tool's issue tracker suggesting to
add support for flags added by Apple in their fork. This has since
happened, so we could possibly switch to python3.pkgs.xattr.
However, I think it's no longer a good idea:
- Bootstrapping-wise a C tool is considerably simpler.
- GHC upstream tests against Apple's xattr(1) implementation in their
CI. Especially now, since they no longer share a direct ancestry,
it seems unwise to assume the tools will behave the same.
Latest 9.6.x minor release is 9.6.7, which is also in Stackage 22.44.
Thus, dropping according to the GHC Deprecation Policy.
This requires to change the bootstrap for GHC 9.8.x and GHC 9.10.x on
some platforms.
Bump the LLVM version used by our GHC packages in preparation for
the LLVM drops. This breaks the LLVM backend; it will be fixed soon
by backporting patches, but that will require a mass rebuild.
Implement a wrapper script to translate the `opt(1)` arguments passed
by the GHC 9.0.2 binary distribution to the equivalent arguments
for the new LLVM pass manager passed by GHC ≥ 9.10 and our
soon‐to‐be‐patched compilers. This ensures that the bootstrap
of GHC 9.4 continues to work on AArch64.
On an earlier version of this change, I built `haskell.compiler.ghc948`
on both `aarch64-linux` and `aarch64-darwin`, and
`haskell.compiler.ghc924` on `aarch64-linux` only (it is already
broken on Darwin). I confirmed that we get functionally identical
store outputs before and after this change, modulo self‐references:
$ cp -a result-before/ before
$ cp -a result-after/ after
$ chmod -R +w before after
$ LANG=C find before -type f -exec \
remove-references-to \
-t $(readlink result-before) \
-t $(readlink result-before-doc) \
'{}' ';'
$ LANG=C find after -type f -exec \
remove-references-to \
-t $(readlink result-after) \
-t $(readlink result-after-doc) \
'{}' ';'
# Darwin only: normalize build user UIDs in the archive files…
$ LANG=C find before -name '*.a' -exec \
sed -i 's/ 360 / 351 /g' '{}' ';'
$ diff -r before after
# Linux only: the `package.cache` files differ, presumably due to
# an unrelated reproducibility issue.
Therefore, bumping this LLVM dependency did not affect the end result
of the bootstrap for the only compilers it is used for.
These binary packages are available for a fixed set of platforms,
all of which support the native code generator. Therefore, the
`llvmPackages` argument was never used. We leave an assertion around,
just in case.
Also, rearrange the GHC‐related release notes to be in order of
most likely to matter to anyone.
Co-authored-by: Wolfgang Walther <walther@technowledgy.de>
It’s questionable whether or not this worked – 32‐bit ARM in
Nixpkgs is already flaky even when cross‐compiling, and I find
it dubious whether much 32‐bit ARM hardware can build modern
GHCs in a bearable amount of time and memory – and figuring out
cross‐compilation of bootstrap GHCs will be a more sustainable way
to keep it working if anyone cares enough to.
Also, rearrange the GHC‐related release notes to be in order of
most likely to matter to anyone.
This was used for bootstrapping GHC on powerpc64le, but it's unclear
whether that actually still works. It makes no sense to pretend to
support it, when it's most likely broken, but we can't even verify.
Also the bootstrap chain will be broken once we drop GHC 8.10.7, so we
might as well drop the whole thing.
Latest 9.8.x minor release is 9.8.4, which is also in Stackage 23.28.
Thus, dropping according to the GHC Deprecation Policy.
(cherry picked from commit 0943cd9574)
Latest 9.8.x minor release is 9.8.4, which is also in Stackage 23.28.
Thus, dropping according to the GHC Deprecation Policy.
(cherry picked from commit 1874b16d38)
