# [Haskell-cafe] Building network package on Windows

Duncan Coutts duncan at well-typed.com
Wed Dec 2 08:04:21 EST 2009

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
> 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 at 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
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).

--