ghc 8.x: fix cross compilation to windows

pkgs/development/compilers/ghc/8.10.7.nix

@@ -106,6 +106,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
@@ -123,7 +129,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
@@ -156,6 +162,13 @@ stdenv.mkDerivation (rec {
     # upstream patch. Don't forget to check backport status of the upstream patch
     # when adding new GHC releases in nixpkgs.
     ./respect-ar-path.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";
+    })
   ] ++ lib.optionals stdenv.isDarwin [
     # Make Block.h compile with c++ compilers. Remove with the next release
     (fetchpatch {

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 .";

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,