Claus Reinke wrote:
Yes, in principle, building on windows with wxWidgets 2.4.2 should be
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;-).
> 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
on MacOSX 2.5.4 -- so everything is fine still. Since the Linux build
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
(like static C++ constructors) -- when ghci loads. When I run a program
ghci, everything is fine. However, ghci keeps the dll loaded and does
reinitialize the library. When running the program again from the
the library is in a random state and (usually) crashes. The fix is not
either the wxWidgets library needs a thorough cleanup to be more
the ghci interpreter needs special code to reload dynamic link
libraries. I like
the last solution but it is a tricky business :-)
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.
ps I only hope Daan will catch up with wxWidgets before the
gap gets too wide, with all his other commitments.