More windows woe
Simon Peyton Jones
simonpj at microsoft.com
Sat Dec 10 10:59:00 UTC 2016
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
| -----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-18.104.22.168'
| > 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 , 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 .
| 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.
| - Ben
|  https://sourceforge.net/p/mingw-
|  https://ghc.haskell.org/trac/ghc/wiki/SurvivingWIndows
More information about the ghc-devs