GHC build fails on Windows 10 if 'Windows subsystem for Linux' is enabled

[mechkg]

At the start of the build Hadrian (or Shake?) executes the configure script which attempts to run the following command:

bash mk/get-win32-tarballs.sh download x86_64

This command fails because ‘bash’ is resolved to the binary provided by Ubuntu on Windows (which is a reverse WINE-like system that allows executing Linux binaries on Windows) instead of the one provided by MSYS. For some reason they are not compatible and it fails.

It was difficult to debug because running that command manually from the MSYS bash worked fine (now I know that it was because it resolved the correct bash binary, but it wasn’t obvious at all at first).

A more robust behaviour would be to run the correct bash binary using the full path and not rely on OS path resolution.

[snowleopard]

@mechkg Thanks for reporting!

So, we need to figure out how to reliably detect the path to bash when running Hadrian inside MSYS that comes with Stack :-S

At the moment we simply do:

cmd ["bash", "mk/get-win32-tarballs.sh", "download", System.arch]

[ndmitchell]

Any chance an explicit "bash.exe" gets the right one?

[mechkg]

How does cmd work? I suspect it might not be passing the correct environment set up by Stack to the subprocess.

If you open a bare Windows command line and run bash, it will run the WSL bash if it is present or nothing at all if it is not (similar bevahiour to cmd during the build), however if you run stack exec bash from the same command line it runs the expected MinGW bash.

[ndmitchell]

Those pieces are usually in the environment variables. cmd leaves those untouched. I suspect stack might be running cmd.exe /c bash - where cmd.exe is the windows command line interpreter.