| We suspect that Alastairs fixes may still leave some issues | with concurrency / potentially blocking threads / ffi (at | least in GHC's default configuration on windows), but we'd | like to see just how far the improvements go, as the next | stable release of GHC is imminent. | | * Could anyone with cvs/fptools/makefile-expertise lend me a hand | * if I try again to build only hslibs/win32 from cvs? Or is it | * completely unreasonable to expect this to work? Claus, and Mike, I'm very grateful to you for having a go at this. Esp now that Julian and Reuben have moved on to pastures new, we rely increasingly on help from other people to keep GHC flying. It's just too broad a system for Simon M and me to maintain every library. I'm no expert on the Win32 library, but: a) No it is not unreasonable to expect it to build, cleanly, starting from scratch. It jolly well ought to. b) I strongly recommend that you build it by checking out fptools/mk, glafp-utils (you get these with fpconfig) fptools/ghc, libraries, hslibs Then build GHC, using practically any installed GHC (later than about 4.02 I think). Then build 'libraries'. Then build 'hslibs', which includes win32. The point here is that we update 'libraries' and 'hslibs' to track the GHC in the tree, so there's no guarantee that it'll work if you compile it with some older GHC. It may, but it may not. c) I use the standard build.mk (build.mk.sample). I don't try to install anything, at least not to start with. Just say use the standard build.mk (or even an empty one) and say 'make'. I did this today, and happily built a HSwin32.o package from scratch. Mike Thomas says he can't build GHC from scratch on Windows. I'm sure you've reported this, Mike, but can you say again what happens to you. (Assuming the setup I outline above.) It's puzzling that it works for me but not for you. Make sure you start from a totally clean tree. Lots of stuff has been changing in the HEAD. Simon