More windows woe

[Simon Peyton Jones]

But meanwhile is there any way to get a working windows build?  I'm totally stalled on all fronts.  

It was ok a few days ago

Thanks

Simon

| -----Original Message-----
| From: Ben Gamari [mailto:ben at well-typed.com]
| Sent: 10 December 2016 03:44
| To: Simon Peyton Jones <simonpj at microsoft.com>; GHC developers <ghc-
| devs at haskell.org>
| Subject: Re: More windows woe
| 
| Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:
| 
| > I see that anything involving ghci fails:
| >
| > /c/code/HEAD/inplace/bin/ghc-stage2 --interactive
| >
| > GHCi, version 8.1.20161209: http://www.haskell.org/ghc/  :? for help
| >
| > ghc-stage2.exe: unable to load package `base-4.9.0.0'
| >
| > ghc-stage2.exe: C:\code\HEAD\inplace\mingw\x86_64-w64-
| mingw32\lib\libmingwex.a: unknown symbol `_lock_file'
| >
| Yes, Tamar and I were working on tracking this down over the last few
| days. The patch (which I will merge after a running validation finishes)
| is D2817.
| 
| In short, the problem is that we recently upgraded the Windows toolchain.
| For better or worse, the new mingw-w64 toolchain now has an atomic printf
| implementation, which requires the use of the _lock_file function
| provided by Microsoft's C runtime. However, the _lock_file symbol is only
| exported by certain variants of msvcrt (e.g. msvcrt90.dll), but not the
| distribution which mingw-w64 uses (apparently due to license
| considerations [1], although the exact reason isn't clear).
| 
| To hack around this, mingw-w64 ships a static library, msvcrt.a, which
| wraps msvcrt.dll and provides hand-rolled implementations of some needed
| symbols, including _lock_file. However, this means that the static
| library msvcrt.a, and the dynamic library msvcrt.dll don't export the
| same set of symbols, which causes GHCi to blow up if dynamically linked.
| Consequently we need to
| 
| All of this coupled with another recent but quite unrelated cleanup
| (D2579) breaking the Windows build when bootstrapped with GHC 7.10, the
| recent testsuite debacle, as well as a number of other Windows quirks
| I've discovered in the past few weeks, meant that figuring all of this
| out took quite some time (which is why the Windows builder *still* isn't
| quite up). On the bright side, one happy side-effort of this is that it
| prompted me to write down some notes on the interactions between the many
| components of our Windows toolchain [2].
| 
| Anyways, we are getting quite close. I expect we'll finally have the
| Windows builder up by next week. Hopefully from that point forth it will
| be considerably harder to break the Windows build.
| 
| Cheers,
| 
| - Ben
| 
| 
| [1] https://sourceforge.net/p/mingw-
| w64/discussion/723797/thread/55520785/
| [2] https://ghc.haskell.org/trac/ghc/wiki/SurvivingWIndows