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

[Johan Tibell]

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/20120208/75ebdf26/attachment-0001.htm>