forked from mirrors/nixpkgs
Merge pull request #132199 from alexfmpe/cross-mingw-ghc
ghc 8.x: fix cross compilation to windows
This commit is contained in:
commit
29a06adb07
|
@ -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 {
|
||||
|
|
|
@ -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 .";
|
||||
|
|
32
pkgs/development/compilers/ghc/rename-numa-api-call.patch
Normal file
32
pkgs/development/compilers/ghc/rename-numa-api-call.patch
Normal file
|
@ -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,
|
Loading…
Reference in a new issue