Claus Reinke wrote:
If anyone does compile up a 6.4.1-compatible version of wxHaskell and is willing to share it, please say so.  
Sounds like there are still some hitches in compiling under windows.  - Conal
    
that is most likely because I tried to build with the current stable wxWidgets 
version instead of the older 2.4.2 recommended by Dan. which is not to say 
that wxHaskell shouldn't try to keep pace with wxWidgets;-).
  
Yes, in principle, building on windows with wxWidgets 2.4.2 should be fairly painless.
> ps I only hope Daan will catch up with wxWidgets before the
>     gap gets too wide, with all his other commitments.
I do try to keep pace with wxWidgets: on GTK wxHaskell uses 2.6.0 by default and
on MacOSX 2.5.4 -- so everything is fine still. Since the Linux build doesn't use
ODBC, I never spotted the faults that you encountered on Windows.

I keep using 2.4.2 on windows since it

1) seems to have just the same set of features as 2.6
2) is very stable
3) is the only version that works well with ghci

About the last point: all the newer versions of wxWidgets rely on static
initializers: these are initialized when the dynamic link library is loaded
(like static C++ constructors) -- when ghci loads. When I run a program from
ghci, everything is fine. However, ghci keeps the dll loaded and does not
reinitialize the library. When running the program again from the command line,
the library is in a random state and (usually) crashes. The fix is not easy:
either the wxWidgets library needs a thorough cleanup to be more stateless, or
the ghci interpreter needs special code to reload dynamic link libraries. I like
the last solution but it is a tricky business :-)

-- Daan.
 
I'm currently trying to build with ghc-6.5 (one of the snapshots after Sigbjorn's
fix, so I'm using an unpatched wxHaskell 0.9.4) and have been a lot more 
successful with wxWindows 2.4.2. The build looks fairly clean and doesn't 
take all that long. No need to meddle with sh/bash, do any of the other
fiightening things mentioned in wxHaskell's cygwin installation guide, or do 
anything to PATH other than adding ghc-6.5/bin, and prefixing Mingw/bin. 
Neither do any of the other problems mentioned in my previous mail appear
in this case. There were only two small things:

- wxWidgets make install didn't copy all of the include files
    to the installation directory (just copying the one file mentioned
    on the wxHaskell building page seems to be sufficient, but I still
    wonder what is going on there)

- ghc-6.5's haddock needs to be told where to find its auxiliary 
    files, which it is searching in the wrong directory 
    (-l c:/ghc/ghc-6.5/docs/html/libraries helps).

The problem I have at the moment is that I'm doing this on a remote
machine, so I can't really test there, and I need to package things up
to copy them here. But "make dist" fails for wxHaskell, with what 
seems to be a cygwin problem:

C:\cygwin\bin\bash.exe (2124): *** fork: can't reserve memory for stack 0x40000 - 0x240000, Win32 error 487
      5 [main] bash 1584 fork_parent: child 2124 died waiting for longjmp before initialization
/bin/bash: fork: No such file or directory
make: *** [wxc-dist] Error 129

(I added SHELL=/bin/bash to makefile, in case that would help, but
as you can see, it didn't). I haven't found any real info about this 
problem, other than that it has been reported with fairly recent
cygwin builds and not fixed in Cygwin DLL 1.5.15-1 release. the 
suggested fix was to try the development snapshots of cygwin.. 
so it may be fixed in the current cygwin already (1.5.16-1 release).

but I don't know how to remote update cygwin (my only access 
point is via said cygwin;-), so this will have to wait till tomorrow.

Apart from that, building with the older wxWidgets version 
and a fixed ghc seems to be painless, as Daan suggested.

cheers,
claus

ps I only hope Daan will catch up with wxWidgets before the
    gap gets too wide, with all his other commitments.