Merge remote-tracking branch 'nixpkgs/master' into staging-next

Conflicts:
	pkgs/development/compilers/ghc/8.10.7.nix
	pkgs/development/compilers/ghc/8.8.4.nix

I've removed the isWindows check from useLdGold in ghc, since that should
be covered by the new hasGold check.

3 files changed, 64 insertions, 1 deletions

diff --git a/pkgs/development/compilers/ghc/8.10.7.nix b/pkgs/development/compilers/ghc/8.10.7.nix
index 7af598da1df..5a59f55cf74 100644
--- a/pkgs/development/compilers/ghc/8.10.7.nix
+++ b/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
@@ -157,6 +163,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 {
diff --git a/pkgs/development/compilers/ghc/8.8.4.nix b/pkgs/development/compilers/ghc/8.8.4.nix
index 81c5a8811ce..e2a65a19791 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
@@ -168,6 +174,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,