Possible regression of cross-compiling TH with mingwW64

[thomasjm]

Describe the bug

I've been trying to cross-compile a project from Linux to Windows, and noticed that several dependencies which depend on TH fail to compile in the same manner described in #1913.

There are a few examples, such as exceptions in TH code that reads from a file with file-embed, as in #1913. But for this issue I'll focus on just building aeson-typescript, where the TH doesn't even do external IO.

This is on x86_64-linux. I've tried with GHC 9.6.6 and GHC 9.8.4, which the current repro uses, and the latest Haskell.nix.

I think #2034 was meant to address these issues, but I think there might have been some regression. I'd note that the comment in overlays/wine.nix became out of date with #2034, which stopped pinning Wine. That comment mentioned Wine 5.4, but Wine on nixpkgs-unstable is up to version 10.0 now.

Steps To Reproduce

git clone [email protected]:codedownio/aeson-typescript.git
cd aeson-typescript
nix build .#windows

The build fails with a message like this (which sort of suggests a locale issue?):

       > wine: failed to open L"C:\\windows\\syswow64\\rundll32.exe": c0000135
       > wine: configuration in L"/build" has been updated.
       > Listening on port 6249
       > iserv-proxy: getBin: Unknown encoding for constructor
       > iserv-proxy-interpreter.exe:<socket:180>:hPutBuf:invalidargument(Invalid a
       > rgument)
       >
       > src/Data/Aeson/TypeScript/Instances.hs:190:25: error: [GHC-87897]
       >     • Exception when trying to run compile-time code:
       >         {handle: <file descriptor: 25>}: GHCi.Message.remoteCall: end of file
       >       Code: Language.Haskell.TH.Quote.quoteExp
       >               i "{[k: string]: #{getTypeScriptType (Proxy :: Proxy a)}}"
       >     • In the quasi-quotation:
       >         [i|{[k: string]: #{getTypeScriptType (Proxy :: Proxy a)}}|]
       >     |
       > 190 |   getTypeScriptType _ = [i|{[k: string]: #{getTypeScriptType (Proxy :: Proxy a)}}|]
       >     |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       > [ 8 of 12] Compiling Data.Aeson.TypeScript.Formatting ( src/Data/Aeson/TypeScript/Formatting.hs, dist/build/Data/Aeson/TypeScript/Formatting.o )

Expected behavior

The pkgsCross.mingwW64 version of the aeson-typescript library should build successfully.

CC @amesgen and @angerman, I'd be very grateful for any help in figuring this out!

[angerman]

@thomasjm I hope to have some time to investigate this next week 😅

[thomasjm]

Thank you!

[thomasjm]

Any chance you'll be able to look at this soon @angerman? I'd love to be able to cross-compile my projects rather than use an actual Windows machine...

[angerman]

I did, but haven't gotten a solution yet :-/

[hamishmack]

Please try replacing pkgsCross.mingwW64 with pkgsCross.ucrt64.

[thomasjm]

Thanks @hamishmack -- just tried it and got the same result. Full output here:

https://gist.github.com/thomasjm/8ccc2ee06dcb9f66bcbe178fb6f9fb99

[thomasjm]

Hi all -- I saw on #2335 that this was described as "the dreaded" issue haha. I'd like to help push it forward if I can. Any chance you could write down what you found out about the problem so far? To me it initially looked like some kind of encoding issue when communicating with this iserv thing.

[hamishmack]

I've done some digging, but I am not sure what is going on.

The issue can be reproduced in the haskell.nix repo with:

nix-build -E '((import ./. {}).pkgs-unstable.pkgsCross.ucrt64.haskell-nix.hackage-package { compiler-nix-name = "ghc984"; name = "aeson-typescript"; }).components.library'

Replacing compiler-nix-name gives:

• ghc966 success
• ghc967 success
• ghc984 fail
• ghc9101 fail
• ghc9122 success

I'm not sure if there was a regression in GHC 9.8 that was fixed by the time 9.12.2 was released or if there is a patch we are not applying to GHC 9.8 and 9.10 that we do apply to 9.6 and 9.12.