I will merge this as soon as I get back from vacation. On Feb 8, 2012 8:54 AM, "Holger Reinhardt" <hreinha...@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 <agocor...@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 <hreinha...@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 <agocor...@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 <hreinha...@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 <agocor...@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 <hreinha...@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 <agocor...@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 <hreinha...@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 <agocor...@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.tib...@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" >> >> >> >> >> > <agocor...@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 <hreinha...@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 <agocor...@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.tib...@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@haskell.org >> >> >> >> >> >> >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> > >> > >> > >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe