-
Notifications
You must be signed in to change notification settings - Fork 842
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
hsc2hs-ghc-9.8.4.exe: fd:3: hGetContents: invalid argument (cannot decode byte sequence starting from... #6670
Comments
Thank you for reporting. Referencing the following (closed), in case it is related: |
My initial hypothesis, which I am going to test, is that this is an upstream issue with the I can reproduce the problem, on Windows 11 in Windows Terminal, by:
The same problem occurs with:
(GHC 9.2.8, which is Windows Terminal is Unicode:
|
It is Cabal (the library) that runs the GHC-supplied
|
To interpret that
|
Noting that @clin1234 reported the problem goes away when using cabal or stack plus ghc 9.10. |
@simonmichael, thanks. I've now confirmed that the same problem occurs with GHC 9.10.1 and updated my post above. |
The error message ( EDIT: No, that was a dead end. The problem manifests itself with the simplest of uses:
where module Dummy where
dummy :: IO ()
dummy = pure () Or, taking Stack entirely out of the equation:
|
The proper solution here is for It seems to use getArgsWithResponseFiles: https://github.com/haskell/hsc2hs/blob/2d6e7a3385526410146e2817fcba3de88b5fc6a8/src/Main.hs#L78 For which there exists no alternative in |
With verbosity:
I then replaced the Hebrew (right-to-left) with Cyrillic (left-to-right) and had a different experience (still a fail) (with verbosity):
|
@hasufell, you are, of course, right about |
@clin1234, I think I have a fix for Applying the fix would involve:
Building the replacement
To locate the
(It would probably be a good idea to preseve the executables supplied with GHC by renaming them first.) |
Which GHC versions are affected? |
@clin1234, another possibility that will likely work - one that is perhaps less daunting - is to configure Stack so that its local-programs-path: D:\sr\programs (My Stack root is I put that non-project specific configuration option in the global configuration file ( You had used GHCup to obtain Stack but you were using Stack (and not GHCup) to manage Stack-supplied GHC versions (which is fine). On Windows, I think GHCup typically puts its GHC versions in |
@hasufell, my best guess is all released non-obsolete GHC versions are affected by the underlying bug. That is because, on Hackage, |
Expected
Successful compilation
Actual
Stack version
Method of installation
Platform
Windows 11 x64
The text was updated successfully, but these errors were encountered: