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/