movefasta/nixpkgs
1
0
Fork 0
mirror of https://github.com/NixOS/nixpkgs.git synced 2025-06-09 19:13:26 +03:00
Code Issues Projects Releases Packages Wiki Activity

haskell.compiler.ghc94: don't roundtrip C compilation via assembly

Browse source 
GHC can be used to compile C sources which causes it to drive the
configured C compiler. This is particularly relevant during GHC's own
compilation, e.g. when building the rts. GHC takes a peculiar approach,
always generating intermediate assembly instead of letting the C
compiler emit object files directly. This causes an assembler check in
clang >= 18 to fail on rts/StgCRun.c, failing the GHC build on darwin
completely.

Later GHC versions don't exhibit this issue since object code is emitted
directly since 9.6. The easiest way to resolve the compilation failure
seems to backport this change. However, the patch only applies on
GHC 9.4 which is done here. The patch may be difficult to backport
further, as the changed code was extensively refactored in GHC 9.4.

Reference #367686.

(cherry picked from commit 16dca700d7)
This commit is contained in:
sternenseemann 2025-05-23 10:52:11 +02:00 • committed by github-actions[bot]
parent 4755e2590b
commit e82afa1894
1 changed files with 38 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

39
pkgs/development/compilers/ghc/common-make-native-bignum.nix
View file

@ -364,7 +364,44 @@ stdenv.mkDerivation (
else
./Cabal-3.2-3.4-paths-fix-cycle-aarch64-darwin.patch
)
];
]
# Before GHC 9.6, GHC, when used to compile C sources (i.e. to drive the CC), would first
# invoke the C compiler to generate assembly and later call the assembler on the result of
# that operation. Unfortunately, that is brittle in a lot of cases, e.g. when using mismatched
# CC / assembler (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12005). This issue
# does not affect us. However, LLVM 18 introduced a check in clang that makes sure no
# non private labels occur between .cfi_startproc and .cfi_endproc which causes the
# assembly that the same version (!) of clang generates from rts/StgCRun.c to be rejected.
# This causes GHC to fail compilation on mach-o platforms ever since we upgraded to
# LLVM 19.
#
# clang compiles the same file without issues whithout the roundtrip via assembly. Thus,
# the solution is to backport those changes from GHC 9.6 that skip the intermediate
# assembly step.
#
# https://gitlab.haskell.org/ghc/ghc/-/issues/25608#note_622589
# https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6877
++ (
if lib.versionAtLeast version "9.4" then
[
# Need to use this patch so the next one applies, passes file location info to the cc phase
(fetchpatch {
name = "ghc-add-location-to-cc-phase.patch";
url = "https://gitlab.haskell.org/ghc/ghc/-/commit/4a7256a75af2fc0318bef771a06949ffb3939d5a.patch";
hash = "sha256-DnTI+i1zMebeWvw75D59vMaEEBb2Nr9HusxTyhmdy2M=";
})
# Makes Cc phase directly generate object files instead of assembly
(fetchpatch {
name = "ghc-cc-directly-emit-object.patch";
url = "https://gitlab.haskell.org/ghc/ghc/-/commit/96811ba491495b601ec7d6a32bef8563b0292109.patch";
hash = "sha256-G8u7/MK/tGOEN8Wxccxj/YIOP7mL2G9Co1WKdHXOo6I=";
})
]
else
[
# TODO(@sternenseemann): backport changes to GHC < 9.4 if possible
]
);
postPatch = "patchShebangs .";