Error with most TH on mingwW64 on GHC 9.4 and 9.6

[amesgen]

Describe the bug

Reading files during TH (e.g. via file-embed) (EDIT: this is just an example, also happens with much more mundane things, see #1913 (comment)) fails when cross-compiling to mingwW64 from x86_64-linux on GHC 9.4 and 9.6.

main :: IO ()
main = putStrLn $(TH.lift =<< TH.runIO (readFile "app/foo.txt"))

Steps To Reproduce

Minimal reproducible example: https://github.com/amesgen/stuff/tree/haskell.nix-mingwW64-TH-readFile-again

Concretely:

 $ nix build github:amesgen/stuff/haskell.nix-mingwW64-TH-readFile-again#ghc944
...
/nix/store/f1yzg91kr20alxcpqwikxwv708irs7xi-iserv-wrapper/bin/iserv-wrapper: line 31:   200 Segmentation fault      (core dumped) WINEDLLOVERRIDES="winemac.drv=d" WINEDEBUG=warn-all,fixme-all,-menubuilder,-mscoree,-ole,-secur32,-winediag WINEPREFIX=$TMP /nix/store/90hdb8v389sxv4xbxgv80w36lfbg1c78-wine-5.4/bin/wine64 $REMOTE_ISERV/iserv-proxy-interpreter.exe tmp $PORT
app/Main.hs:8:17: error:
    • Exception when trying to run compile-time code:
        ghc-iserv terminated (1)
      Code: (TH.lift =<< TH.runIO (readFile "app/foo.txt"))
    • In the untyped splice:
        $(TH.lift =<< TH.runIO (readFile "app/foo.txt"))
  |
8 | main = putStrLn $(TH.lift =<< TH.runIO (readFile "app/foo.txt"))
  |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Full logs

 $ nix build github:amesgen/stuff/haskell.nix-mingwW64-TH-readFile-again#ghc961
...
iserv-proxy-interpreter.exe: Could not load Object Code /nix/store/xg4301nc9ygcpkpw8d5rp0wr81n299p6-x86_64-w64-mingw32-ghc-9.6.1/lib/x86_64-windows-ghc-9.6.1/ghc-prim-0.10.0/HSghc-prim-0.10.0.o.
<no location info>: error: unable to load unit `ghc-prim-0.10.0'

Full logs

Expected behavior

It should compile fine, as it does e.g. on 9.2.

 $ nix build github:amesgen/stuff/haskell.nix-mingwW64-TH-readFile-again#ghc927 # works fine

Additional context

Maybe it is again due to a Wine version problem, cf. #1487?

[amesgen]

Actually, this is not specific to reading files; similar errors occur with much more trivial TH, e.g. one gets similar errors as soon as the library depends on the text library, even if it is not imported anywhere and the TH is entirely trivial such as

main = putStrLn $ show $(TH.lift (1 :: Int))

So something about TH seems to be very broken for mingwW64.

EDIT: At least the text deficiency is already known:

haskell.nix/test/th-dlls/default.nix

Lines 22 to 23 in c0011f6

	# TH breaks for ghc 9.4.3 cross compile for windows if the library even
	# just depends on the `text` package (this may be related to the C++ dependency).

The original issue (in particular the MRE) is independent of this though.

[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]

AFAICT this is currently being worked on in #2034

[amesgen]

This was indeed fixed in #2034, but one sometimes has to use reinstallableLibGhc = false;, otherwise one still gets weird segfaults:

---> Starting iserv-proxy-interpreter.exe on port 5528
---| iserv-proxy-interpreter.exe should have started on 5528
0048:err:systray:initialize_systray Could not create tray window
008c:err:setupapi:SetupDefaultQueueCallbackW copy error 1812 L"@C:\\windows\\system32\\drivers\\wineusb.sys,-1" -> L"C:\\windows\\inf\\wineusb.inf"
wine: failed to open L"C:\\windows\\syswow64\\rundll32.exe": c0000135
wine: configuration in L"/build" has been updated.
�[?25lListening on port 5528
�[?25h0024:err:seh:call_stack_handlers invalid frame 00007FFFFF68EF38 (0000000000022000-0000000000220000)
0024:err:seh:NtRaiseException Exception frame is not in stack limits => unable to dispatch exception.
iserv-proxy: <socket: 6>: hGetBufSome: resource vanished (Connection reset by peer)

�[;1m<no location info>: �[;1m�[31merror�[0m�[0m�[;1m:�[0m�[0m�[;1m ghc-iserv terminated (1)�[0m�[0m

Will close this issue now, but if I or someone else encounters a situation where reinstallableLibGhc = false; is infeasible, it might make sense to open a separate issue for that.