[web-devel] [Haskell-cafe] network-2.3.0.10 compiled for ghc 7.4.1 windows

Johan Tibell johan.tibell at gmail.com
Mon Feb 13 18:34:23 CET 2012


I've merged and pushed the changes to the "stable" branch on GitHub. If
someone could verify that it works fine on Windows, I'll make another
release.

In addition to running whatever program you're interested in, also run:

cabal clean
autoreconf
cabal configure --enable-tests
cabal build
cabal test

All tests should pass.

-- Johan


On Wed, Feb 8, 2012 at 11:04 AM, Johan Tibell <johan.tibell at gmail.com>wrote:

> I will merge this as soon as I get back from vacation.
> On Feb 8, 2012 8:54 AM, "Holger Reinhardt" <hreinhardt at gmail.com> wrote:
>
>> Having discussed the issue privately with Alberto, I've found another bug
>> and updated my pull request [1]. Using that code it should be possible to
>> build the network library on Windows using MSys on GHC 7.4.1.
>>
>> [1] https://github.com/haskell/network/pull/25
>>
>> 2012/2/8 Alberto G. Corona <agocorona at gmail.com>
>>
>>> yes i did it,.
>>>
>>> the error is as follows:
>>>
>>> shop.exe: NetworkSocket.hsc:(948,3)-(1007,23): Non-exhaustive patterns
>>> in case
>>>
>>> I will download network form hackage and will do it form the beginning. .
>>>
>>>
>>>
>>> 2012/2/8 Holger Reinhardt <hreinhardt at gmail.com>:
>>> > Did you run "cabal clean" before rebuilding with Git Bash? And can you
>>> post
>>> > the exact runtime error you get?
>>> >
>>> > 2012/2/8 Alberto G. Corona <agocorona at gmail.com>
>>> >
>>> >> I switched to Git bash and the runtime error produced by the library
>>> >> is the same.
>>> >> This error may be produced because  the configuration it does not
>>> >> detect the netwiorkin related includes such is socket.h. This does not
>>> >> exist neither in the ghc installation neither in GIT/Mingw
>>> >>
>>> >>
>>> >> 2012/2/7 Holger Reinhardt <hreinhardt at gmail.com>:
>>> >> > I just use the version of MSys that is included with Git [1]. This
>>> puts
>>> >> > a
>>> >> > "Git bash" icon on your desktop which you can then use to build the
>>> >> > network
>>> >> > library.
>>> >> >
>>> >> > [1] http://code.google.com/p/msysgit/
>>> >> >
>>> >> >
>>> >> > 2012/2/7 Alberto G. Corona <agocorona at gmail.com>
>>> >> >>
>>> >> >> Nothing bur a long history of failures. The problem is the
>>> >> >> configuration and versioning of MinGW and MSys. This  is a
>>> nighmare.
>>> >> >>
>>> >> >> 2012/2/7 Holger Reinhardt <hreinhardt at gmail.com>:
>>> >> >> > Oh you are using Cygwin. I'm using MSys so this is why I cannot
>>> >> >> > reproduce
>>> >> >> > your problem. Is there anything preventing you from using MSys?
>>> >> >> >
>>> >> >> >
>>> >> >> > 2012/2/7 Alberto G. Corona <agocorona at gmail.com>
>>> >> >> >>
>>> >> >> >> The "problem" this time is in "Configure" :
>>> >> >> >>
>>> >> >> >> case "$host" in
>>> >> >> >> *-mingw32)
>>> >> >> >>        EXTRA_SRCS="cbits/initWinSock.c, cbits/winSockErr.c,
>>> >> >> >> cbits/asyncAccept.c"
>>> >> >> >>        EXTRA_LIBS=ws2_32
>>> >> >> >>        CALLCONV=stdcall ;;
>>> >> >> >> *-solaris2*)
>>> >> >> >>        EXTRA_SRCS="cbits/ancilData.c"
>>> >> >> >>        EXTRA_LIBS="nsl, socket"
>>> >> >> >>        CALLCONV=ccall ;;
>>> >> >> >> *)
>>> >> >> >>        EXTRA_SRCS="cbits/ancilData.c"
>>> >> >> >>        EXTRA_LIBS=
>>> >> >> >>        CALLCONV=ccall ;;
>>> >> >> >> esac
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> Since I´m cross-compiling with cygwin, the variable Host does
>>> not
>>> >> >> >> contain ¨*-muingw32"  but "i686-pc-cygwin"
>>> >> >> >>
>>> >> >> >> changing the case , the library incorporates the lost C coded
>>> files.
>>> >> >> >>
>>> >> >> >> Now the library links fine win imported, but there is a runtime
>>> >> >> >> error:
>>> >> >> >>
>>> >> >> >> NetworkSocket.hsc:(948,3)-(1007,23): Non-exhaustive patterns in
>>> case
>>> >> >> >>
>>> >> >> >> maybe it is due to some other preprocessor directive mismatch
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> 2012/2/7 Holger Reinhardt <hreinhardt at gmail.com>:
>>> >> >> >> > Did you also change the files in the /cbits/ folder? Because
>>> they
>>> >> >> >> > also
>>> >> >> >> > check
>>> >> >> >> > for HAVE_WINSOCK_H.
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> > 2012/2/7 Alberto G. Corona <agocorona at gmail.com>
>>> >> >> >> >>
>>> >> >> >> >> The code is evolving and none of the versions match exactily
>>> with
>>> >> >> >> >> the
>>> >> >> >> >> patch, but substituting HAVE_WINSOCK by HAVE WINSOCK2 in
>>> these
>>> >> >> >> >> files
>>> >> >> >> >> solves the compilation problem at least in the network
>>> 2.3.0.10
>>> >> >> >> >> version from hackage.
>>> >> >> >> >>
>>> >> >> >> >> However it produces the same undefined references when this
>>> >> >> >> >> library
>>> >> >> >> >> is
>>> >> >> >> >> imported in my application. It seems that some object code
>>> is not
>>> >> >> >> >> included in the final library.  I verified that at least
>>> some of
>>> >> >> >> >> these
>>> >> >> >> >> undefined references correspond with  C code in the source,
>>> but
>>> >> >> >> >> somehow this is not included in the object library....
>>> >> >> >> >>
>>> >> >> >> >> 2012/2/7 Johan Tibell <johan.tibell at gmail.com>:
>>> >> >> >> >> > Note that there are two branches on github, master and
>>> stable.
>>> >> >> >> >> > You
>>> >> >> >> >> > want
>>> >> >> >> >> > the
>>> >> >> >> >> > latter.
>>> >> >> >> >> >
>>> >> >> >> >> > On Feb 7, 2012 8:23 AM, "Alberto G. Corona"
>>> >> >> >> >> > <agocorona at gmail.com>
>>> >> >> >> >> > wrote:
>>> >> >> >> >> >>
>>> >> >> >> >> >> This is quite different.
>>> >> >> >> >> >> I don´t know how but I was looking at some other older
>>> patch
>>> >> >> >> >> >> around
>>> >> >> >> >> >> the same issue and I supposed that it was the one refered
>>> by
>>> >> >> >> >> >> Yohan
>>> >> >> >> >> >> Tibell.
>>> >> >> >> >> >>
>>> >> >> >> >> >> I´ll try your patch.
>>> >> >> >> >> >>
>>> >> >> >> >> >> Thanks!.
>>> >> >> >> >> >>
>>> >> >> >> >> >> 2012/2/7 Holger Reinhardt <hreinhardt at gmail.com>:
>>> >> >> >> >> >> > Hi,
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > (I submitted the patch that Johan linked to)
>>> >> >> >> >> >> > Network/Socket/Internal.hsc has the following code:
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > #if defined(WITH_WINSOCK) || defined(cygwin32_HOST_OS)
>>> >> >> >> >> >> > type CSaFamily = (#type unsigned short)
>>> >> >> >> >> >> > #elif defined(darwin_HOST_OS)
>>> >> >> >> >> >> > type CSaFamily = (#type u_char)
>>> >> >> >> >> >> > #else
>>> >> >> >> >> >> > type CSaFamily = (#type sa_family_t)
>>> >> >> >> >> >> > #endif
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > You have patched this part to always use 'unsigned
>>> short'.
>>> >> >> >> >> >> > But
>>> >> >> >> >> >> > the
>>> >> >> >> >> >> > real
>>> >> >> >> >> >> > issue is that WITH_WINSOCK is not defined, even though
>>> it
>>> >> >> >> >> >> > should
>>> >> >> >> >> >> > be. The
>>> >> >> >> >> >> > reason for this lies in include/HsNet.h:
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > #if defined(HAVE_WINSOCK_H) &&
>>> !defined(cygwin32_HOST_OS)
>>> >> >> >> >> >> > # define WITH_WINSOCK  1
>>> >> >> >> >> >> > #endif
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > The problem here is that it checks for HAVE_WINSOCK_H,
>>> but
>>> >> >> >> >> >> > the
>>> >> >> >> >> >> > configure
>>> >> >> >> >> >> > script never defines this variable. Instead it
>>> >> >> >> >> >> > defines HAVE_WINSOCK2_H.
>>> >> >> >> >> >> > It
>>> >> >> >> >> >> > seems that the network library used Winsock1 in the
>>> past and
>>> >> >> >> >> >> > in
>>> >> >> >> >> >> > the
>>> >> >> >> >> >> > transition to Winsock2 someone forgot to change a few
>>> of the
>>> >> >> >> >> >> > #ifdefs.
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > My patch just changes all occurences of HAVE_WINSOCK_H
>>> >> >> >> >> >> > to HAVE_WINSOCK2_H.
>>> >> >> >> >> >> > You might want to try that and report back if it works
>>> for
>>> >> >> >> >> >> > you.
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > 2012/2/7 Alberto G. Corona <agocorona at gmail.com>
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> Hi Johan,
>>> >> >> >> >> >> >> The patch is not for the current version of network
>>> and the
>>> >> >> >> >> >> >> code
>>> >> >> >> >> >> >> is
>>> >> >> >> >> >> >> quite different. Basically it is necesary to  define
>>> this
>>> >> >> >> >> >> >> variable
>>> >> >> >> >> >> >> as
>>> >> >> >> >> >> >> "unsigned short" that is the thing intended in the
>>> patch.
>>> >> >> >> >> >> >> however
>>> >> >> >> >> >> >> I
>>> >> >> >> >> >> >> put it by brute force, without regard of the
>>> prerpocessor
>>> >> >> >> >> >> >> directives.
>>> >> >> >> >> >> >> With this change the code compiles well with:
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >>
>>> http://neilmitchell.blogspot.com/2010/12/installing-haskell-network-library-on.html
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> However my compiled library lack the methods defined as
>>> >> >> >> >> >> >> foreign.
>>> >> >> >> >> >> >> I´ll
>>> >> >> >> >> >> >> keep trying.
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> 2012/2/6 Johan Tibell <johan.tibell at gmail.com>:
>>> >> >> >> >> >> >> > Hi,
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > Someone recently contributed a fix that should make
>>> >> >> >> >> >> >> > network
>>> >> >> >> >> >> >> > build
>>> >> >> >> >> >> >> > with
>>> >> >> >> >> >> >> > 7.4: https://github.com/haskell/network/pull/25
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > Can you see if that works for you? I haven't yet had
>>> time
>>> >> >> >> >> >> >> > to
>>> >> >> >> >> >> >> > merge
>>> >> >> >> >> >> >> > and
>>> >> >> >> >> >> >> > release that fix (I'm on vacation.)
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > -- Johan
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> _______________________________________________
>>> >> >> >> >> >> >> Haskell-Cafe mailing list
>>> >> >> >> >> >> >> Haskell-Cafe at haskell.org
>>> >> >> >> >> >> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>> >> >> >> >> >> >
>>> >> >> >> >> >> >
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >
>>> >> >
>>> >
>>> >
>>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20120213/837a6cc7/attachment-0001.htm>


More information about the web-devel mailing list