Regression of cross-compiling TH

[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 git@github.com: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.

[thomasjm]

I just edited the title to be more general because I found this doesn't just affect Windows targets; it seems to affect all cross-compilation like aarch64-multiplatform.

[thomasjm]

FWIW, I tried my repro again after #2385 landed and got a slightly different failure. The relevant logs are:

[ 1 of 12] Compiling Data.Aeson.TypeScript.LegalName ( src/Data/Aeson/TypeScript/LegalName.hs, dist/build/Data/Aeson/TypeScript/LegalName.o )
[ 2 of 12] Compiling Data.Aeson.TypeScript.Types ( src/Data/Aeson/TypeScript/Types.hs, dist/build/Data/Aeson/TypeScript/Types.o )
[ 3 of 12] Compiling Data.Aeson.TypeScript.TypeManipulation ( src/Data/Aeson/TypeScript/TypeManipulation.hs, dist/build/Data/Aeson/TypeScript/TypeManipulation.o )
[ 4 of 12] Compiling Data.Aeson.TypeScript.Internal ( src/Data/Aeson/TypeScript/Internal.hs, dist/build/Data/Aeson/TypeScript/Internal.o )
[ 5 of 12] Compiling Data.Aeson.TypeScript.Instances ( src/Data/Aeson/TypeScript/Instances.hs, dist/build/Data/Aeson/TypeScript/Instances.o )
---> Starting iserv-proxy-interpreter.exe on port 9437
To re-use the same wine-prefix and remote-iserv, set the following environment variables:
export WINEPREFIX=/build/tmp.WfRgE7PzMP
export REMOTE_ISERV=/build/tmp.uzuFyYxzUN
---| iserv-proxy-interpreter.exe should have started on 9437
004c:err:vulkan:vulkan_init_once Wine was built without Vulkan support.
004c:err:systray:initialize_systray Could not create tray window
0094: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
002c:err:setupapi:do_file_copyW Unsupported style(s) 0x10
00f8:err:ntoskrnl:ZwLoadDriver failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\winebth": c00000e5
002c:err:setupapi:SetupDiInstallDevice Failed to start service L"winebth" for device L"ROOT\\WINE\\WINEBTH", error 1359.
002c:err:setupapi:SetupDiInstallDevice Failed to control service L"winebth" for device L"ROOT\\WINE\\WINEBTH", error 1062.
002c:err:setupapi:do_file_copyW Unsupported style(s) 0x10
0120:err:setupapi:do_file_copyW Unsupported style(s) 0x10
0120:err:setupapi:do_file_copyW Unsupported style(s) 0x10
Listening on port 9437

After this, it just hangs.