summary refs log tree commit diff
path: root/pkgs/development/compilers/ghc
diff options
context:
space:
mode:
authorAlexandre Esteves <alexandre.fmp.esteves@gmail.com>2021-09-09 02:33:52 +0100
committerAlexandre Esteves <alexandre.fmp.esteves@gmail.com>2021-09-09 03:35:17 +0100
commitbd5f47022c3994840d2daf7867cac66c9ba2963f (patch)
tree597fd436e98a2949fd4a84228545ac576e2cc327 /pkgs/development/compilers/ghc
parenteea8e3eacec12fe4e46d3ecb8e3cbbd03a10b2f0 (diff)
downloadnixpkgs-bd5f47022c3994840d2daf7867cac66c9ba2963f.tar
nixpkgs-bd5f47022c3994840d2daf7867cac66c9ba2963f.tar.gz
nixpkgs-bd5f47022c3994840d2daf7867cac66c9ba2963f.tar.bz2
nixpkgs-bd5f47022c3994840d2daf7867cac66c9ba2963f.tar.lz
nixpkgs-bd5f47022c3994840d2daf7867cac66c9ba2963f.tar.xz
nixpkgs-bd5f47022c3994840d2daf7867cac66c9ba2963f.tar.zst
nixpkgs-bd5f47022c3994840d2daf7867cac66c9ba2963f.zip
ghc8.8.4: fix mingw build
Diffstat (limited to 'pkgs/development/compilers/ghc')
-rw-r--r--pkgs/development/compilers/ghc/8.8.4.nix22
-rw-r--r--pkgs/development/compilers/ghc/rename-numa-api-call.patch32
2 files changed, 52 insertions, 2 deletions
diff --git a/pkgs/development/compilers/ghc/8.8.4.nix b/pkgs/development/compilers/ghc/8.8.4.nix
index 7838c5a8652..1f207059756 100644
--- a/pkgs/development/compilers/ghc/8.8.4.nix
+++ b/pkgs/development/compilers/ghc/8.8.4.nix
@@ -2,7 +2,7 @@
 
 # build-tools
 , bootPkgs
-, autoconf, automake, coreutils, fetchurl, perl, python3, m4, sphinx
+, autoconf, automake, coreutils, fetchpatch, fetchurl, perl, python3, m4, sphinx
 , bash
 
 , libiconv ? null, ncurses
@@ -114,6 +114,12 @@ let
     GhcRtsHcOpts += -fPIC
   '' + lib.optionalString targetPlatform.useAndroidPrebuilt ''
     EXTRA_CC_OPTS += -std=gnu99
+  ''
+  # While split sections are now enabled by default in ghc 8.8 for windows,
+  # they seem to lead to `too many sections` errors when building base for
+  # profiling.
+  + lib.optionalString targetPlatform.isWindows ''
+    SplitSections = NO
   '';
 
   # Splicer will pull out correct variations
@@ -131,7 +137,7 @@ let
   # Use gold either following the default, or to avoid the BFD linker due to some bugs / perf issues.
   # But we cannot avoid BFD when using musl libc due to https://sourceware.org/bugzilla/show_bug.cgi?id=23856
   # see #84670 and #49071 for more background.
-  useLdGold = targetPlatform.linker == "gold" || (targetPlatform.linker == "bfd" && !targetPlatform.isMusl);
+  useLdGold = targetPlatform.linker == "gold" || (targetPlatform.linker == "bfd" && !targetPlatform.isMusl && !targetPlatform.isWindows);
 
   runtimeDeps = [
     targetPackages.stdenv.cc.bintools
@@ -167,6 +173,18 @@ stdenv.mkDerivation (rec {
     # Fix documentation configuration which causes a syntax error with sphinx 4.*
     # See also https://gitlab.haskell.org/ghc/ghc/-/issues/19962
     ./sphinx-4-configuration.patch
+    # cabal passes incorrect --host= when cross-compiling
+    # https://github.com/haskell/cabal/issues/5887
+    (fetchpatch {
+            url = "https://raw.githubusercontent.com/input-output-hk/haskell.nix/122bd81150386867da07fdc9ad5096db6719545a/overlays/patches/ghc/cabal-host.patch";
+      sha256 = "sha256:0yd0sajgi24sc1w5m55lkg2lp6kfkgpp3lgija2c8y3cmkwfpdc1";
+    })
+
+    # error: 'VirtualAllocExNuma' redeclared as different kind of symbol
+    # name conflict between rts/win32/OSMem.c and winbase.h from the mingw-w64 runtime package
+    # Renamed to match ghc8.8:
+    # https://gitlab.haskell.org/ghc/ghc/-/commit/4b431f334018eaef2cf36de3316025c68c922915#20d64c0bdc272817149d1d5cf20a73a8b5fd637f
+    ./rename-numa-api-call.patch
   ];
 
   postPatch = "patchShebangs .";
diff --git a/pkgs/development/compilers/ghc/rename-numa-api-call.patch b/pkgs/development/compilers/ghc/rename-numa-api-call.patch
new file mode 100644
index 00000000000..747d7a81a11
--- /dev/null
+++ b/pkgs/development/compilers/ghc/rename-numa-api-call.patch
@@ -0,0 +1,32 @@
+diff --git a/rts/win32/OSMem.c b/rts/win32/OSMem.c
+--- a/rts/win32/OSMem.c
++++ b/rts/win32/OSMem.c
+@@ -41,7 +41,7 @@ static block_rec* free_blocks = NULL;
+ typedef LPVOID(WINAPI *VirtualAllocExNumaProc)(HANDLE, LPVOID, SIZE_T, DWORD, DWORD, DWORD);
+
+ /* Cache NUMA API call. */
+-VirtualAllocExNumaProc VirtualAllocExNuma;
++VirtualAllocExNumaProc _VirtualAllocExNuma;
+
+ void
+ osMemInit(void)
+@@ -52,8 +52,8 @@ osMemInit(void)
+     /* Resolve and cache VirtualAllocExNuma. */
+     if (osNumaAvailable() && RtsFlags.GcFlags.numa)
+     {
+-        VirtualAllocExNuma = (VirtualAllocExNumaProc)GetProcAddress(GetModuleHandleW(L"kernel32"), "VirtualAllocExNuma");
+-        if (!VirtualAllocExNuma)
++        _VirtualAllocExNuma = (VirtualAllocExNumaProc)(void*)GetProcAddress(GetModuleHandleW(L"kernel32"), "VirtualAllocExNuma");
++        if (!_VirtualAllocExNuma)
+         {
+             sysErrorBelch(
+                 "osBindMBlocksToNode: VirtualAllocExNuma does not exist. How did you get this far?");
+@@ -569,7 +569,7 @@ void osBindMBlocksToNode(
+                On windows also -xb is broken, it does nothing so that can't
+                be used to tweak it (see #12577). So for now, just let the OS decide.
+             */
+-            temp = VirtualAllocExNuma(
++            temp = _VirtualAllocExNuma(
+                           GetCurrentProcess(),
+                           NULL, // addr? See base memory
+                           size,