This is the libffi version that GHC 8.10.7 was released with.
libffi >= 3.4 in nixpkgs is no longer getting configured with the
configure flag that enabled GHC to continue working.
See https://gitlab.haskell.org/ghc/ghc/-/issues/20051.
Fixes#324384.
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
This refactor should simplify the code a little bit and make future
changes easier. I. e. for cross compiling GHC we'll have to update the
tools in the GHC settings file and calculate the host->target tool paths
for later use. Having a ready function for this will make this a lot
easier.
This is a left over to do from #308776. Rebasing existing PR (prior
to #308776) would need to be rebased on a change before the commit
included in this PR.
elfutils is used in the RTS (rts/Libdw.c), i.e. it will be used on the
target platform.
Tested via pkgsCross.gnu32.haskellPackages.ghc [1], though #304605 needs
to be cherry-picked for elfutils to build.
[1]: nix-shell -E 'with import ./. { crossSystem = "i686-linux"; };
mkShell { nativeBuildInputs = [haskellPackages.ghc ]; }'
The common expression is a little messy to avoid rebuilds. It can be
cleaned up in a second step.
`9.4.8.fixme.nix` is used temporarily so that git's rename detection
gets where common-make-native-bignum.nix is coming from.
8.10.7 keeps its expression since it uses integer-simple which changes
the expression's interface. This is unfortunately very annoying to
reflect in a common expression.
This makes the hadrian expressions much simpler as we no longer need to
thread through extra arguments for special workarounds.
common-hadrian.nix decides in one place which patches we need and
directly applies them to the source used to build everything.
We'll want to (slowly) unify the source used by the different
derivations we use to build GHC. As a first step, use the same base
source for building GHC and all hadrian related packages. This is
achieved by wrapping the fetcher result in `srcOnly` to apply GHC
patches immediately.
To modify the patches (and source) used by GHC we now have a changed
overriding interface for >= 9.6:
```
oldGhc.override {
ghcSrc = oldGhc.src.overrideAttrs (oldAttrs: {
src = …;
patches = …;
});
}
```
When we are building compiler for a platform we can execute ourselves,
we can build a proper stage2 compiler which unlocks some features that
are interesting for e.g. pkgsStatic.
The resulting compiler is technically a native compiler that's prefixed.
By trying to migitate the conflict between two files on a case
insensitive fs, we will inevitably end up with a different hash than on
case sensitive filesystems. To work around this, we just delete the
directory that contains the offending files — luckily it is not
important to the build of GHC.
Unfortunately, we are running into trouble linking dependencies of
hadrian against the libraries of the clock package with 9.6.3 and
9.6.4 _bindists_. My current suspiscion is that this is caused by
some kind of discrepancy between the toolchain used by GHC upstream
and us that persists from the configure step used when building the
bindist. The problem seems to be somewhat localized to hsc2hs (hence
clock is an issue), with GHC 9.6.4 bindists even passing a flag to
ld that is not supported by our version of cctools.
The problem is not fully diagnosed, so take the speculation above
with a grain of salt.
As a workaround, we can use the source built GHC 9.6 which is, of
course, configured with our toolchain in the environment.
This disables building dynamic libraries for GHC 9.4.x and before, when enableShared and
enableProfiledLibs are set to false. Currently this only disables dynamic linking of GHC
itself, but still creates dynamic libraries.
The hadrian-based GHC 9.6+ already disable building dynamic libraries via the no_dynamic_libs
transformer in this case.
The reason for this happening before was, that the default was assumed to be "v p dyn", of
which "p" was taken away when profiled libs were disabled. But this would unconditionally
enable the dyn way. Using the BUILD_PROF_LIBS flag in this case will let GHC's config.mk.in
script make the proper decisions about which GhcLibWays to build.
Testing for isScript was flawed, as 9.6.3 started having bash
completions in their tarball which don't have a shebang (which is used
by isScript to detect a shell script).
Best reviewed by viewing
diff -u pkgs/development/compilers/ghc/9.{2.4,6.3}-binary.nix
main change are that we drop the `isHadrian` mechanism, since all
bindists are produced by hadrian and alpine bindists are also available
dynamically linked now.
The reasoning given for disabling it is flawed: In most cases, sphinx
and its dependencies are already in the binary cache, since we only need
them as build tools—sphinx for the build platform is just the normal
pkgs.sphinx, since it doesn't care about targetPlatform.
We just need to disable it when the buildPlatform is also musl, so we
avoid pulling in sphinx in pkgsMusl.
https://www.stackage.org/ lists the latest LTS snapshot for any GHC
version which, on the flipside, lets us discover which versions don't
have a corresponding LTS snapshot. There is really no reason to keep
around GHCs that only appeared in some nightly snapshot way back.
haskell.compiler.ghc924: remove at 9.2.4
haskell.compiler.ghc942: remove at 9.4.2
haskell.compiler.ghc943: remove at 9.4.3
haskell.compiler.ghc944: remove at 9.4.4
haskell.compiler.ghc962: remove at 9.6.2
In this situation, haddock would not be built by hadrian, as there is no
stage0:exe:haddock target by default. (We should eventually try adding
one.) If haddock is enabled and the build->host haddock missing, Cabal
tries using the build->build haddock which may fail to load the
documentation from the interface files produced by the build->host
GHC (e.g. due to a mismatch between dynamic and static linking).
Add regression tests to haskell-updates jobset.
Resolves#275304.
This ports our infamous patch for `Cabal` which cheesily prevents an
output cycle for derivations that use separate bin outputs where
references caused by the `Paths_*` module can't be eliminated by the GHC
aarch64-darwin codegen backend.
See also
- the original issue #140774,
- the original patch for GHC 9.2 #216857
- the ported patch for GHC 9.4
f6f780f129
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
We want to remove llvmPackages_6, but it is the only version GHC 8.6.5
supports. Luckily, we actually don't need LLVM in any case, since all
X86 architectures have native codegen for Darwin and Linux, as well as
POWER for Linux. Consequently, we can just pass `null` and add an extra
assert to make this more transparent to future tinkerers.
GHC has a native backend for POWER and SPARC. This is relevant to 8.6.5
binary in the case of POWER where we actually have a bindist and don't
need to include LLVM.
