GHC and Win32 API - help wanted
Mike Thomas" <email@example.com
Fri, 28 Jun 2002 10:01:24 +1000
Moral support but little else below....
> As noone has responded so far, I have to conclude that this
> is quite an infrequently used package..
> - noone using ghc + win32 API?
> - noone using ghc + hgl on windows?
Although I feel the Win32 package is important I am finding it impossible to
build GHC from CVS in order to debug my main project which, (unfortunately
for your own interest in HGL), uses ObjectIO, so I felt that I was unable to
offer anything coherent to you.
I can't even get as far as the Win32 library while building GHC from scratch
at the moment.
> 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.
I suspect that the problems I had with profiling the ObjectIO library
recently reported on the bugs list are also caused by thread issues, but I
can't test this hypothesis due to the problems outlined above.
> * 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?
> The fresh greencard output seems to depend on parts of the ffi
> syntax that weren't supported in ghc-5.02.2, so I'd have to try with
> ghc-5.03.20020208 (the latest windows installer snapshot).
When I tried building CVS GHC with this package I got a compiler which would
> But if I try setting GHC_PKG_INPLACE today, there's absolutely no
> change! The setting in fptools/mk/build.mk seems to be ignored now?
Yes, I haven't found a way of getting around this problem myself other than
hard wiring the compiler (possibly in target.mk from memory?)
> Any helpful souls out there, who could lead me through the jungle of
> bewildering makefiles tomorrow (target date for feature completeness
> for the next release)?
Sorry not to be of more help.
> If not, I'll just drop the issue (those who reported the problem
> earlier seem to have given up? and Simon Thompson, who last ran into
> it, does now get acceptable performance from Hugs/HGL for his app).
Even more lost,