Regression: Mingw-w64 runtime failure: 32 bit pseudo relocation

[amesgen]

Describe the bug

Certain programs fail at runtime when compiled via mingwW64 after #2156:

Mingw-w64runtimefailure:
32 bit pseudo relocation at 00000001400017FE out of range, targeting 00000000004
08160, yielding the value FFFFFFFEC040695E.

• Build system: x86_64-linux
• GHC version: GHC 9.6.6 (also tested with GHC 9.10.1)
• Haskell.nix version (or commit) used: 071f213

Steps To Reproduce

The following program is the most minimal example I managed to produce so far:

import GHC.Types.SrcLoc

main :: IO ()
main = putStrLn "yeah"

data Foo = Foo PsLoc

Here, GHC.Types.SrcLoc comes from ghc or ghc-lib-parser. I tried to inline the definition of PsLoc, or put it into a separate minimal package, but that made the bug go away in the cases I tried.

This minimal reproducible example is also availabe here:

https://github.com/amesgen/stuff/tree/haskell.nix-mingwW64-runtime-bug

nix build github:amesgen/stuff/haskell.nix-mingwW64-runtime-bug

Expected behavior

The program should execute fine (especially as the Foo data type above isn't even used), as it did before #2156.

Additional context

The example above is minimized from trying to compile Ormolu with haskell.nix after #2156.

The error message is already mentioned in the haskell.nix codebase, so maybe this rings a bell:

haskell.nix/overlays/windows.nix

Lines 26 to 34 in 9549b8a

	# If we build libffi with high entropy, we keep running into
	#
	# > Mingw-w64 runtime failure:
	# > 32 bit pseudo relocation at 0000000140117CE6 out of range, targeting 00006FFFFFF18160, yielding the value 00006FFEBFE00476.
	#
	# This however also means, pretty much all of our haskell packages will need to be built with this as well.
	libffi = prev.libffi.overrideAttrs (_: {
	LDFLAGS = "-Wl,--disable-dynamicbase,--disable-high-entropy-va,--image-base=0x400000";
	});

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[amesgen]

Just confirming that the problem is still there on current master, i.e. fc8633a.

[HeinrichApfelmus]

(Random bystander) Does that error occur only when cross-compiling, or is that an issue with GHC 9.6.6 on Windows?

[amesgen]

It doesn't happen with a native Windows GHC; and even with haskell.nix, the mingwW64 GHC 9.6.6 didn't have that issue before #2156, so it seems to be specific to the details of the cross compilation infra in haskell.nix.