Hello, Here is an update, in case anyone else runs into the same problem. My understanding, is that the problem was caused by a mistake in the "configure" script for the "network" package, which after (correctly) detecting that IPv6 functionality was not available on my platform, it (incorrectly) tried to "gain" this functionality by redefining the version of my platform. Concretely, apparently I have "Windows Vista Basic Home Edition", which seems to identify itself as version 0x400, while the missing functions are only available on versions of windows

= 0x501.

My workaround was to: 1. checkout the network package from the repository on code.haskell.com 2. modify configure.ac to comment out the section where it sets the windows version to 0x501 3. autoreconf 4. build using the usual cabal way Another thing to watch out for: if you already have packages that were built against the old version of network, they will continue to use that. So, I had to: 1. remove all of these packages, 2. remove the old version of network (to avoid confusion), and 3. then resintall the packages. It would be nice if we had a more automatic way to do that (perhaps we do, but I don't know it?). It seems that if this is not done GHC could panic, which is what happened to me. I am not sure why that happened but I am guessing that it was related to the fact that interface to the package changed without its version changing. In general, it seems a bad idea that the same version of the network package exhibits different APIs, depending on the configuration of the underlying system. -Iavor On Sat, Jun 6, 2009 at 9:43 PM, Iavor Diatchki wrote:

Hi, I have been trying to build the package "network" from hackage (version 2.2.1.3) on Windows Vista, and I could really use some help.

Building on the command line, or under cygwin completely failed (command line due to cabal not being able to execute something---possibly configure---although it would not say; cygwin first due to lack of gcc, which is tested but, apparently, the outcome ignored, and after gcc was installed some incompatibility with the header files which were detected but reported unusable).

I managed to build the library under MinGW with msys without serious obstacles.  I can also build my package against the result and all is well.  Unfortunately, if I try to use my package to build an executable application I get a linker error, reporting a missing symbol during linking: C:\Users\diatchki\AppData\Roaming\cabal\network-2.2.1.3\ghc-6.10.3/libHSnetwork-2.2.1.3.a(Socket.o):fake:(.text+0xb014): undefined reference to `getnameinfo' collect2: ld returned 1 exit status

Now, "getnameinfo" is present in the header files, and it is also defined in the library ws2_32.a which is being passed to GHC so I am not sure what is going on.  Any ideas?  Searching the web suggests that the problem may be somehow related to the standard calling conventions but I don't really understand.  Also, if I understand correctly, this functionality is related to IPv6 support, which I do not need at the moment, so it would be great if it could be easily disabled in some way.

Any ideas, suggestion, workarounds, etc. would be greatly appreciated, -Iavor

PS: I am using GHC 6.10.3

On Sat, 2009-06-06 at 21:43 -0700, Iavor Diatchki wrote:

Hi, I have been trying to build the package "network" from hackage (version 2.2.1.3) on Windows Vista, and I could really use some help.

Unfortunately, if I try to use my package to build an executable application I get a linker error, reporting a missing symbol during linking: C:\Users\diatchki\AppData\Roaming\cabal\network-2.2.1.3\ghc-6.10.3/libHSnetwork-2.2.1.3.a(Socket.o):fake:(.text+0xb014): undefined reference to `getnameinfo' collect2: ld returned 1 exit status

I saw some other people run into this today.

Now, "getnameinfo" is present in the header files, and it is also defined in the library ws2_32.a which is being passed to GHC so I am not sure what is going on. Any ideas?

Searching the web suggests that the problem may be somehow related to the standard calling conventions but I don't really understand.

Right. The getnameinfo in ws2_32.a uses the stdcall calling convention. The actual linker symbol for it is "_getnameinfo@28". If it used the ccall convention then it's linker symbol name would be "_getnameinfo". The FFI decl for getnameinfo uses ccall. So that's why we get the error. The current version uses a C wrapper for this function (for unrelated reasons) and this has the side effect that the C compiler picks up the correct calling convention from the C header files. We would be able to catch errors like this if we had a tool that would check the Haskell FFI decls match the C headers. Of course c2hs already does this, but only for generating correct FFI decls in the first place. It cannot be used in a mode where it checks existing code. That might be a useful extension though since very few projects seem to use c2hs to generate correct imports in the first place. It also does not currently check stdcall vs ccall calling convention but it could fairly easily be extended to do so (since it parses those attributes). -- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/