Windows: clang-based GHC versions (GHC 9.4.1 onwards) fail if space in path to ghc executable

[codeweaverx]

Please follow the steps below for reporting a bug in Stack:

Make sure that you are using the latest release (currently Stack 3.1.1). See the
upgrade instructions
to upgrade.

Please use the following schema for your bug report:

General summary/comments (optional)

Attempted to install the Haskell Stack, and as a sanity check, created a new project with "stack new" as per usual, stepped into it, and did a "stack build". Build fails with:

C:\hs\Playground>stack build
ghc-9.6.6.exe: could not execute: C:\Users\MyUser\ Name\AppData\Local\Programs\stack\x86_64-windows\ghc-9.6.6\lib\../mingw/bin/clang.exe

Error: [S-6374]
While building simple Setup.hs (scroll up to its section to see the error) using:
C:\Users\MyUser Name\AppData\Local\Programs\stack\x86_64-windows\ghc-9.6.6\bin\ghc-9.6.6.exe -rtsopts -threaded -clear-package-db -global-package-db -hide-all-packages -package base -main-is StackSetupShim.mainOverride -package Cabal-3.10.3.0 C:\sr\setup-exe-src\setup-CKvAmRb3.hs C:\sr\setup-exe-src\setup-shim-CKvAmRb3.hs -o C:\sr\setup-exe-cache\x86_64-windows\tmp-Cabal-simple_CKvAmRb3_3.10.3.0_ghc-9.6.6.exe
Process exited with code: ExitFailure 1

(noting that my user name has been replaced... my windows user name has a space in it as indicated)

windows 11, very recently clean install (within the last week)
No other versions of ghc, stack, or anything haskell related on machine.

Steps to reproduce

1. Uninstall any previous edition of Stack (all options checked during uninstall)
2. Verification of removal of anything down in %APPDATA%
3. manual removal of C:\sr
4. manual removal of previous attempts to build ("stack build") a new project
5. installation of Stack 3.1.1
6. bringing up new Command window
7. "cd \hs"
   (I set up a directory junction in the root of my C drive called hs to point at my project folder in case any dreaded pathname length issues were relevant -- it seems to make no difference whether I go to that trouble or not)
8. "stack new Playground"
9. "cd Playground"
10. "stack build"

I'm baffled. On searching for this 'could not execute' error, almost everything points to pathname length issues from years ago. I'm not sure what I missed, but I wouldn't expect the very most basic install-and-sanity-check test to fail on such an unexotic Windows setup.

Expected

A working build out of the box.

Actual

The standard version of the output was above. The --verbose version is as follows:

stack new Playground
cd Playground
stack build --verbose

https://gist.github.com/codeweaverx/fbde0b6b550d6fe11aae266b033fe231

Stack version

stack --version
Version 3.1.1, Git revision 8127279fb48012945f47f73167a5ecbce5692965 x86_64 hpack-0.37.0

Method of installation

• Official binary

Platform

Windows 11 Pro Version 10.0.22631 Build 22631
Frame.Work 16 laptop (AMD Ryzon 7040 series)

[mpilgrem]

@codeweaverx, thanks for reporting. I am also a Windows user and this reminds me of this problem I had in 2019 (although your sympton is different):

• Windows: Need local-programs-path with no space in path, if no short (8 dot 3) name exists for default #4726

If it is an upstream 'space on the path' problem (and it looks like it may well be), there are two solutions:

• Relatively easy: Move Stack's 'programs' directory elsewhere (to somewhere without a space on the path). This is what I do myself: I've moved it into the Stack root (where it would be on Unix-like operating systems) (configuration in config.yaml) :

  local-programs-path: C:\sr\programs

• Longer term and unattractive as an immediate solution: don't use Windows user names that cause a 'space on the path'. Microsoft itself tries to avoid them these days, when you set up a new user account.

[mpilgrem]

I tried to, and did, reproduce with local-programs-path: D:\test with spaces\programs and it is definitely an upstream (GHC 9.6.6) problem with a 'space on the path'. We can get full (Stack, Cabal (the library), GHC) verbosity with:

stack --verbose build --cabal-verbosity=3 --ghc-options=-v

That shows that Cabal (the library) commands (re-formatted):

Running: "D:\test with spaces\programs\x86_64-windows\ghc-9.6.6\bin\ghc-9.6.6.exe" 
"-hide-all-packages" 
"-c" "C:\Users\mike\AppData\Local\Temp\ghc5F74.c" 
"-o" "C:\Users\mike\AppData\Local\Temp\ghc5F75.o" 
"-haddock" 
"-v" 
"-fhide-source-paths"

and GHC 9.6.6 falls over with:

[warn] *** C Compiler:
[warn] "D:\\test\ with\ spaces\\programs\\x86_64-windows\\ghc-9.6.6\\lib\\../mingw/bin/clang.exe" 
"-x" "c" 
"-c" "C:\Users\mike\AppData\Local\Temp\ghc5F74.c" 
"-o" "C:\Users\mike\AppData\Local\Temp\ghc5F75.o.tmp" 
"-Wa,-mbig-obj" 
"-Wimplicit" 
"-include" "D:\test with spaces\programs\x86_64-windows\ghc-9.6.6\lib\x86_64-windows-ghc-9.6.6\rts-1.0.2\include\ghcversion.h" 
"-ID:\test with spaces\programs\x86_64-windows\ghc-9.6.6\lib\x86_64-windows-ghc-9.6.6\base-4.18.2.1\include" 
"-ID:\test with spaces\programs\x86_64-windows\ghc-9.6.6\lib\x86_64-windows-ghc-9.6.6\ghc-bignum-1.3\include" 
"-ID:\test with spaces\programs\x86_64-windows\ghc-9.6.6\lib\x86_64-windows-ghc-9.6.6\rts-1.0.2\include" 
"-ID:\test with spaces\programs\x86_64-windows\ghc-9.6.6\lib\../mingw/include" 
"-D_UCRT" 
"--rtlib=compiler-rt"
...
[warn] ghc-9.6.6.exe: could not execute: D:\\test\ with\ spaces\\programs\\x86_64-windows\\ghc-9.6.6\\lib\\../mingw/bin/clang.exe

[codeweaverx]

• Relatively easy: Move Stack's 'programs' directory elsewhere (to somewhere without a space on the path). This is what I do myself: I've moved it into the Stack root (where it would be on Unix-like operating systems) (configuration in config.yaml) :

  local-programs-path: C:\sr\programs

I will try this, and report back in. If nothing else, this issue will at least be searchable by others to find a resolution. Provided it works.

This is my preferred option at this point, as its the only tool I use that has this problem. (So far!)

Onward to testing!

• Longer term and unattractive as an immediate solution: don't use Windows user names that cause a 'space on the path'. Microsoft itself tries to avoid them these days, when you set up a new user account.

If that's the case, they need to make that a part of the Windows install process, because there's simply been no warning that this is now a Microsoft recommended action.

All this being said... and I'm guessing this is an unpopular decision, but if this is ghc's problem, maybe they should fix it. It's been an age, it appears.

Anyway. I'll update whether this worked before day's end.

[mpilgrem]

@codeweaverx, there is something in Stack's online FAQ under 'Windows-related' and at https://docs.haskellstack.org/en/stable/topics/stack_root/#__tabbed_1_2 but neither are easy to find. I'll make it more visible.

EDIT: I have raised at GHC's repository:

• https://gitlab.haskell.org/ghc/ghc/-/issues/25204

[codeweaverx]

mpilgrem, you're a rock star.

So, Update!

My process to get it working as been:

1. from clean, install Stack, but at C:\sr in the installer for the install location.
2. run stack at least once doing something useful, like the stack new Playground from my steps, so the config.yaml is available. (Or preserve your old .yaml before uninstalling).
3. edit the config.yaml as per your suggestion above.

Did it twice just to make sure it worked.

And I'm back in business.

Except compiling with the -fllvm setting on (since I use that in some of my projects) yields no errors except an access violation crash running the resulting executable, no idea why, but I can track that as a separate problem.

Yeah, I was thinking that the Stack guide to installing in windows makes a warning about antivirus software. It could also make a warning about this space problem, and offer your two workarounds.

Any way Stack could detect this situation and offer to move everything to C:/sr and fix the config.yaml? Or throw up a suggestion? I mean, GHC could take a while to address this.

Anyway.

You're an absolute rock star. :)

[mpilgrem]

@codeweaverx, may I check a couple of things?

Before it was fixed, did you experience Stack message S-8432 about "Stack's 'programs' path contains a space character and has no alternative short ('8 dot 3') name..." (I assume you did not).

And is short '8 dot 3' name creation enabled on your C:\ drive? That is (in a terminal with adminsitrator privileges) what does:

fsutil 8dot3name query C:

report? On my system, it reports:

The volume state is: 0 (8dot3 name creation is ENABLED)
The registry state is: 1 (8dot3 name creation is DISABLED on all volumes)

Based on the above settings, 8dot3 name creation is DISABLED on "C:"

[codeweaverx]

To answer in reverse order, my response to

fsutil 8dot3name query C:

is

`
The volume state is: 0 (8dot3 name creation is ENABLED)
The registry state is: 2 (Per volume setting - the default)

Based on the above settings, 8dot3 name creation is ENABLED on "C:"
`

Regarding S-8432...

I don't recall seeing that, or the message warning about the space character and 8 dot 3 names, but I also wasn't looking for it. I'm moderately sure I haven't seen it during all my tests, but if it came up once at the beginning, I wouldn't remember.

That said, I uninstalled and reinstalled in its 'broken' state, to see if I could spot it. The dump from that build, right from the first command window I open after complete default installation of stack, is as follows:

https://gist.github.com/codeweaverx/374df8023fd203e8e56fd3f89de13803

That error message doesn't come up.

@mpilgrem Happy to help. I know I get frustrated when stuff like this happens and I just want to get on and make cool things. Biggest thing stopping anyone from experimenting or adopting tools like this is a baffling barrier to entry. :)

I hope some of this helps.

[mpilgrem]

@codeweaverx, that is very useful. S-8432 is currently triggered when (a) there is a space in the 'long' path to Stack's 'programs' and (b) there is no '8 dot 3' short path. In your case, there is a short path - so S-8432 is not triggered - but the presence of a short path does not stop a clang-based version of GHC (GHC 9.4.1 or more recent) from failing if there is a space in the long path.

That will help me think about revising the test for S-8432.

[mpilgrem]

This will have been a problem since GHC 9.4.1 was released (7 August 2022) and more significant when Stackage LTS 21.0 (GHC 9.4.5) was released (20 June 2023). The reason it may not have been experienced by many Windows users until now is that, since Windows 8 (released 2012), Windows Out of Box Experience (OOBE) has picked a username for a Microsoft Account based on the first 5 characters of the email address for the account and it has taken a Local Account to introduce a space character.