Hi, I like Windows. I like networks. I love GHC 6.12.1. Having all three in combination would be fantastic :-) Given the Haskell platform will certainly include network (as an ex-GHC package), does anyone from the haskell-platform team want to pick up the Windows pieces and put together a working network? I've got a locally patched version of network, which I'm using with great success - but that's not much benefit to the rest of the community. Thanks, Neil On Tue, Feb 16, 2010 at 11:10 PM, Claus Reinke <claus.reinke@talk21.com> wrote:

...

1) Install Cygwin 1.7 (include autoreconf)

..

...

4) Change all instances of CALLCONV to stdcall 5) cabal install

Please can you apply the attached patch, which should be compatible with Linux/Mac too. I found lots of references to CALLCONV all over the place, but couldn't figure out where it started/ended up - my attempts at #define were rather unsuccessful. Could you please change the logic so Windows gets stdcall as standard?

That part rings a bell, as the opengl binding had the same issue when dropping out of ghc's extralibs: those packages tend to be integrated into ghc's build system (or one version thereof), which sets things like CALLCONV. This particular setting tended to happen (ghc's build system has changed since I last looked, and I can't check right now) in configure (generated from configure.ac), by simply checking the build's $host variable for '*-mingw32'.

This doesn't work when building on cygwin (even when using the mingw tool chain, configure will see cygwin as the host), and the simple workaround was only documented for ghc builds, not for the packages depending on ghc's build system.

If that information is still relevant, you should be able to get around the CALLCONV issue when building from cygwin by passing a configure option. Here is the example that used to do the trick for building opengl/glut from cygwin:

  cabal install opengl glut --configure-option="--host=i386-unknown-mingw32" --reinstall

A better solution would be for configure to test for the gcc tool chain, not the host environment, before setting CALLCONV. Might apply to other packages that have dropped out of the old extralibs.

Hope this helps, Claus

Hi Johan,

Sorry about not getting back to you earlier, things have been quite hectic around here.

Here too :-)

I think we need a co-maintainer for network that actually uses Windows daily and has the time and experience to have the library keep up with changes affecting that platform (i.e. new versions of GHC and/or Windows). I have a local Windows XP install in a virtual machine that I use for testing before making releases but using it is quite painful.

Agreed. Alas, that is not me. If the platform has network, then someone in the platform team might be best. If network was in the platform and worked reliably then I'd rather never compile/install network, since I usually use it only as a dependency to other packages I use.

In your original email you mentioned that you changed all the occurrences of CALLCONV to stdcall. While this makes everything compile for you it is the wrong thing for other platforms which don't use stdcall. The CALLCONV define is supposed to expand to the right thing for each platform and it has worked in the past and it worked the last time I tried it on Windows XP/GHC 6.12. We need to figure out why it doesn't work for you.

I know my fix is Windows only, I wasn't aiming for portability, just simplicity. As Claus subsequently said, --configure-option="--host=i386-unknown-mingw32" makes it work for me, so perhaps the configure script is getting the wrong platform? Thanks, Neil