Re: [wxhaskell-users] announce: wxHaskell 0.9.4, windows bug fix release

[Daan L. <da...@cs...>]

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.
>
>
>  
>