-
Notifications
You must be signed in to change notification settings - Fork 208
[Win10] Compilation fails for 8.4.2 version #550
Comments
@alanz should i move this issue to alanz/ghc-exactprint? |
Try doing just That warning on ghc-exactprint is normal, and not a problem. |
@alanz
|
Probably related: https://ghc.haskell.org/trac/ghc/ticket/11748 |
sigh...
|
What version of stack are you using? It needs a fairly recent one, and I recommend the current one (1.7.1). Any experienced windows users able to help here? |
@alanz latest one available, 1.7.1 |
The only other thing I can suggest is to delete the .stack-work directory
and try again, there may be some old state in it.
…On 8 May 2018 at 10:11, Vladislav Shtepin ***@***.***> wrote:
@alanz <https://github.com/alanz> latest one available, 1.7.1
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#550 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAZAB9g5X9IzJc4aRifB0xjuvorQASt6ks5twVNPgaJpZM4T1itx>
.
|
Ok, will try when i get home. |
|
I'm using the latest also, 1.7.1. |
@Anrock This won't fix the issue itself but have you considered trying windows subsystem for Linux instead of mingw? |
@razvan-panda yeah, something wasn't working last time i tried, don't remember what. I guess i'll try again sometime. |
FWIW, I was using WSL and getting the same issue. I've since switched to Arch, I'll let you know if the problem persists on Linux as a host OS. |
Here's an issue in Stack that seems to explain the root cause:
I wonder if there is a way to fix the project dependencies to make sure that we're only ever compiling against the same version of the PS: as a last resort, there is also the horrible way: clearing out of ALL of stack's various package repositories ( |
In fact it looks like Win32-2.6.4.1 has never been in a Stackage snapshot, despite that version being a dependency in GHC 8.4.2:
(from @cryptoquick's error log). Here's the Win32 dependency for the GHC binary And a similar dependency for what I think is the (TIL: GHC is a very complex project :P) I wonder if there is a reason that Stackage doesn't pin its package versions to the same ones used in the |
Oh hello, here's an issue in Stackage for just this problem! It looks like a fix was attempted but it was reverted, and then implemented in stackage-curator instead. I think that when I will try to build it locally, generate a snapshot (probably this is possible?), and confirm whether or not HIE will compile. |
@johnsonwj do i understand correctly that some next stackage nightly will fix this issue? I have no idea what stackage-curator is. |
Win32 hasn't been explicitly included in a stackage snapshot since |
I will confirm this and PR updates to the stack files if they end up working for me. I am worried that LTS 9 and 10 will be broken for Windows unless for some reason new snapshots are generated for those versions of GHC. However, one possible glimmer of hope is that the version of |
I based the "GHC Win32 Dependency" column on the most recent version of For the problematic setups, I will try a couple things:
If those solutions work I'll PR the changes to the |
@johnsonwj tried it (nightlies after 2018-05-03 and adding Win32 with speicific version to extra-deps), didn't work for me. Same error. Will check again now, though. |
@Anrock, have you tried the most recent nightly for the 8.4.2 build? |
Disregard my previous message, for
Not sure how to fix this, any advice? @alanz nightlies from 2018-05-13 have dependency conflict
I'm trying to fix it now. |
Thanks. We need to bump forward to a current one from time to time. |
Bumped |
With a little help from `cabal new-build` and the plan.json it generates, I
end up with compilation proceeding for
```
extra-deps:
- apply-refact-0.5.0.0
- constrained-dynamic-0.1.0.0
- haddock-api-2.19.0.1
- haddock-library-1.5.0.1
- haskell-lsp-0.2.2.0
- haskell-lsp-types-0.2.2.0
- syz-0.2.0.0
- temporary-1.2.1.1
```
…On 15 May 2018 at 21:51, Vladislav Shtepin ***@***.***> wrote:
Bumped temporary upper bound in all listed places and got same error
about broken haddock-api...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#550 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAZAB1f3h8mLwtLZOs7sgdeM24NQTg2_ks5tyzG1gaJpZM4T1itx>
.
|
@alanz nah, tried that too. Anyway: success! I haven't found a way to properly fix that broken package issue, so i've just deleted whole %STACK_ROOT% and it was gone. Succesfully built with |
Is this going to affect everyone who's used a one of the bad snapshots? If manually blowing away STACK_ROOT is the only way to get it to build on Windows it might be useful to put a note in the readme |
I know that the latest stack (1.7.1) installs different GHC versions from the prior ones. This may cause issues for snapshot artifacts built with the prior compiler installation, and then mixed in with the new one. I know that as a precaution I blew away my entire |
@johnsonwj probably. When i tried to check your table after successful build and used nightly-05-03 without curator fix - broken haddock package appeared again. |
I have a version that builds with the current nightly, and uses an appropriate haddock-api/haddock-library. See #571, which I will merge as soon as CI passes. |
Microsoft Windows [Version 10.0.16299.371]
HIE at 97f67d4
Running
stack build --copy-compiler-tool
results in failure with following output:The text was updated successfully, but these errors were encountered: