Nightly ghc-9.0.2 has Win32-2.12 (was 2.10)

[Release-Candidate]

I don't know how or where to report errors of the nightlies or propose changes to the YAML, so I'm doing that here. Sorry, if that's the wrong place.

The new nightlies (using GHC 9.0.2) don't compile on Windows, because the package Win32-2.10.0.0 doesn't compile. A C header file is missing (actually the C include directory isn't set when compiling).

Solution

use Win32-2.10.1.0 instead of Win32-2.10.0.0

Error Message

The error is not finding winnls_compat.h:
error: NLS.hsc:56:10: fatal error: winnls_compat.h: No such file or directory

See also haskell/win32#162

[juhp]

Hmmm, that is indeed problematic.

Actually I see that ghc-9.0.2 ships with Win32-2.12.0.1.

[juhp]

Thanks very much for reporting this - obviously a LTS 19 blocker:
so I went ahead and pushed a fix. I guess we forgot to bump Win32 when updating to 9.0.2.
Hopefully this will fix the next Nightly snapshot.

Also nice issue number ;-)

Unfortunately we don't have a Windows builder for Stackage (ie we don't build with Win32) - so sometimes these kind of problems crop up.

[Release-Candidate]

You're welcome.

But there is a problem with foundation and Win32 >= 2.12.0.0.

Win32 added explicit exports in version 2.12.0
https://github.com/haskell/win32/releases/tag/v2.12.0.0
haskell/win32@fbc49f8#diff-3c294c5dd8b170586cad01c72d6ffd35225608811de64b538677cfde2c0b7d64
which breaks foundation, that uses the C bindings directly.

Foundation\Time\StopWatch.hs:73:9: error:
 * Variable not in scope:
 c_QueryPerformanceCounter :: Ptr a0 -> IO a1
 * Perhaps you meant `queryPerformanceCounter' (imported from System.Win32.Time)

See: haskell-foundation/foundation#557

[bergmark]

I think the next LTS should be on 9.0.2 since 9.0.1 had some pretty severe bugs. From what I hear, professional users would not like to use 9.0.1. I would prefer to include foundation even if it doesn't work on windows, hopefully it will get patched and we can make sure to upgrade it at that point.

[Release-Candidate]

It does work with an older version of Win32 (2.10.0.1 <= V < 2.12.0.0), I have used 2.10.0.1 and that did work OK, so the upper bounds proposed by @sjakobi in haskell-foundation/foundation#557 will do.

I also just added a PR to foundation to add compatibility with the newer versions of Win32 (haskell-foundation/foundation#558).

[bergmark]

In general, stackage snapshots are tied to the versions that ship with GHC (https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries/version-history)

For users of our snapshots they can add an extra-dep to override the version.

We have forgotten to sync Win32 with GHC releases multiple times and it always causes problems for someone.

[juhp]

Though it is surprising that 9.0.2 bumped the major version of Win32 - I don't think that has happened in recent history.

https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries/version-history

[Bodigrim]

I would prefer to include foundation even if it doesn't work on windows, hopefully it will get patched and we can make sure to upgrade it at that point.

In such case LTS 19 would be pretty much unusable on Windows: foundation is a transitive dependency of cryptonite, memory, tls, etc.

[juhp]

So can someone here say clearly if adding a upperbound to Win32 in current Stackage Nightly would work?
ie with stack build results to back it :-)

eg does say stack --resolver nightly Win32-2.10.1.0 http-conduit work?

What is the difference between 2.10.1.0 and 2.10.1.1?

[bergmark]

i'll try it on my windows box, last time i tried haskell on windows i was supposed to run weird shell commands and something chocolatey so I never got anything to work.

[bergmark]

stack --resolver nightly-2022-01-20 build foundation Win32-2.10.1.0 works for me.

Cheers to the ghcup team, first time installing on windows just worked for me.

[bergmark]

building against Win32-2.10.1.1 also works

[bergmark]

What is the difference between 2.10.1.0 and 2.10.1.1?

i can't find a changelog or commit related to this release...

[bergmark]

Seems like those releases are identical

$ diff -q Win32-2.10.1.0/ Win32-2.10.1.1/
Common subdirectories: Win32-2.10.1.0/Graphics and Win32-2.10.1.1/Graphics
Common subdirectories: Win32-2.10.1.0/Media and Win32-2.10.1.1/Media
Common subdirectories: Win32-2.10.1.0/System and Win32-2.10.1.1/System
Files Win32-2.10.1.0/Win32.cabal and Win32-2.10.1.1/Win32.cabal differ
Common subdirectories: Win32-2.10.1.0/cbits and Win32-2.10.1.1/cbits
Common subdirectories: Win32-2.10.1.0/include and Win32-2.10.1.1/include

$ diff Win32-2.10.1.0/Win32.cabal Win32-2.10.1.1/Win32.cabal
2c2
< version:        2.10.1.0
---
> version:        2.10.1.1

[bergmark]

forgot the -r to diff:

 diff Win32-2.10.1.0/System/Win32/Types.hsc Win32-2.10.1.1/System/Win32/Types.hsc
280c280
< #if defined(__IO_MANAGER_WINIO__)
---
> ##if defined(__IO_MANAGER_WINIO__)
282c282
< #else
---
> ##else
284c284
< #endif
---
> ##endif
286c286
< #if defined(__IO_MANAGER_WINIO__)
---
> ##if defined(__IO_MANAGER_WINIO__)
296c296
< #endif
---
> ##endif

[Release-Candidate]

i'll try it on my windows box, last time i tried haskell on windows i was supposed to run weird shell commands and something chocolatey so I never got anything to work.

Don't use the Chocolatey package(s), use the official installer from https://docs.haskellstack.org/en/stable/install_and_upgrade/#windows

My Windows machine has a puny N4000, so you have been faster installing and compiling everything than me just compiling some needed new packages :-)

So can someone here say clearly if adding a upperbound to Win32 in current Stackage Nightly would work? ie with stack build results to back it :-)

eg does say stack --resolver nightly Win32-2.10.1.0 http-conduit work?

Yes, works. I had to add some extra-deps suggested by Stack, this is the stack.yaml i used:

resolver:
  nightly-2022-01-20
allow-newer: false
packages:
  - .
extra-deps:
  - directory-1.3.7.0@sha256:4d59f9714700e69d139084b47204fc91f13f31546aac39d666279996192b0d11,2940
  - process-1.6.13.2@sha256:a6530a5698796e29d85817f74ca3ae20d2172fb9fa52b492c2e6816e1306bfe8,2963
  - time-1.12.1@sha256:af1fafc1fb66e3d0afb66fb5ab8629f74c038bebd42c234b581aff7abc201089,6295
system-ghc: false

$ stack build http-conduit Win32-2.10.1.0
...
Completed 75 action(s).

Does not work using Win32-2.10.0.0
$ stack build http-conduit Win32-2.10.0.0
...
Win32 > error: NLS.hsc:56:10: fatal error: winnls_compat.h: No such file or directory

What is the difference between 2.10.1.0 and 2.10.1.1?

The fix of the install-includes needed by 9.0.2 (9.0.1 compiles Win32-2.10.0.0 without errors, nightly-2021.12.19 worked for me on Windows).
haskell/win32@954bc43

Backports for GHC 9.0.x
https://github.com/haskell/win32/releases/tag/v2.10.1.1

[Bodigrim]

You must bump Win32 to a version used by GHC 9.0.2 bindist, otherwise you end up with boot packages (such as filepath and directory) built against Win32-2.12 and everything else against Win32-2.10, which is literally welcome to cabal hell, stack edition.

I guess the best way is to do a right, but hard thing and remove foundation with all downstream dependencies from Stackage. This will provide maintainers an incentive to straighten things out.

[juhp]

Hmm, I just posted a mail to ghc-devs about this (in the ghc-9.0.2 announce thread).
If anyone knows of an upstream ghc gitlab issue, do link to it too, thanks

[juhp]

(Btw perhaps we could have a GH action to run ./check on Windows -
though dunno if it would have helped catch this particular problem.)

[juhp]

Okay, I was searching for a possible pathological example: maybe ihaskell? (does that support Windows??)
Is there a better example?

stack --resolver nightly Win32-2.10.1.1 ihaskell ?

[Release-Candidate]

Okay, I was searching for a possible pathological example: maybe ihaskell? (does that support Windows??)

No, ihaskell needs unix (it really doesn't build on Windows).

[bergmark]

You must bump Win32 to a version used by GHC 9.0.2 bindist, otherwise you end up with boot packages (such as filepath and directory) built against Win32-2.12 and everything else against Win32-2.10, which is literally welcome to cabal hell, stack edition.

This makes sense, for some reason I thought that Win32 would not be affected by this 🤷

I guess the best way is to do a right, but hard thing and remove foundation with all downstream dependencies from Stackage. This will provide maintainers an incentive to straighten things out.

I'm not sure about this. It would make it clearer to maintainers that windows support is an issue, and it would keep the snapshot consistent on Windows. But foundation works fine on other platforms, and we do allow platform-specific packages so foundation could temporarily be considered just that. What do you think?

(Btw perhaps we could have a GH action to run ./check on Windows - though dunno if it would have helped catch this particular problem.)

That would be nice! but it wouldn't have caught this compile time issue. I suppose that this would only catch cases where dependencies are modified based on the platform? I don't think that's a common thing to do.

[juhp]

I dunno - TLS support is a pretty big deal these days and there is talk on the linked haskell-trustee ticket of maybe not even fixing foundation for 2.12 at this time even though there is an open PR :-/

[Bodigrim]

@juhp See haskell-infra/hackage-trustees#330 (comment)

It would make it clearer to maintainers that windows support is an issue, and it would keep the snapshot consistent on Windows. But foundation works fine on other platforms, and we do allow platform-specific packages so foundation could temporarily be considered just that. What do you think?

@bergmark Leaf packages, which have a hard dependency on unix, never compiled under Win and never will are probably fine. At least a snapshot is still self-consistent, it's just that a user cannot provide unix package. A pretty popular package, which used to build under Win and which presumably will be buildable again, but fails to built from snapshot now, is a different matter. And it's kinda confusing to provide an LTS snapshot with explicitly conflicting bounds: foundation has been recently revised with Win32 < 2.12.

Windows users are already at disadvantage in Haskell ecosystem, and leaving them without usable LTS series does not really help with industrial adoption and stability.

Maybe base LTS 19 on GHC 8.10? FWIW there were some very tentative plans (https://gitlab.haskell.org/ghc/homepage/-/merge_requests/96/diffs) to release GHC 8.10.8.

[juhp]

Maybe base LTS 19 on GHC 8.10?

That is not really an option - we create LTS major releases from Nightly, which is currently already on 9.0.2.

If the "ecosystem" is treating Windows as a second class platform, then I tend to agree with Adam that we don't really have much choice here but to proceed with what we have. I can't say I am happy, but I don't think we can delay a ghc-9.0 LTS release indefinitely - one can only hope some sense will come, and tls might start building on Windows ghc-9.0 again later with the boot Win32 version.

Otherwise it would be better to have a quick ghc-9.0.3 release IMO based on Win32-2.10 to avert the current issue.

[Bodigrim]

CC @myShoggoth

[juhp]

Vincent has released basement-0.0.13 and foundation-0.0.27 which hopefully should help resolve this.

If all goes well they should be in the next Nightly snapshot.

[juhp]

Could anyone here retest with latest nightly on Windows? No hacks should be needed now hopefully

eg stack --resolver nightly build tls or so.

[torgeirsh]

"stack --resolver nightly-2022-03-03 build tls" builds successfully on Windows here.