views:

231

answers:

3

I am working on wrapping a large number of .h and .lib files from native C++ to Managed C++ for eventual use as a referenced .dll in C#.

I have the .lib files linked in and everything has been going smoothly so far. Upon wrapping the latest .h file, I hit a snag when 2 functions came back with the link error:

error LNK2019: unresolved external symbol __imp__htonl@4 referenced in function "public: void __thiscall Field::setCharacter(unsigned char,int)" (?setCharacter@Field@@QAEXEH@Z) myutils.lib

I have referenced "myutils.lib" in the linker options, so that shouldn't be the issue.

What's strange is that I have about 20 functions in this particular .h file and all of the rest are linking just fine except for 3 functions.

Any ideas?

A: 

Are you sure the signatures match? Be sure to checked for signed-ness and const-ness. Also, make sure functions aren't inlined.

eduffy
From the .h file: void setCharacter( unsigned char c, int startBit );From the wrapper:void setCharacter( unsigned char c, int startBit ) { m_NativeField->setCharacter(c, startBit); };From my understanding, the functions should be fully defined in the lib file that I am referencing. I can provide the symbol export if that would help too.Does anyone know how to decipher the code output from the linker...ie, what does "__imp__htonl@4", etc. mean?
TomO
Are the three functions that aren't exported all one-liners like that one? Are they the only short functions?
eduffy
A: 

The missing symbol is __imp__htonl@4, which is a C++ mangled name for htonl, which is a function that converts a long value from host to network order. The @4 is used to mangle the input parameters and is part of C++ support for overloaded functions to allow the linker to resolve the right function w/o name collisions.

Make sure that you are linked to the network library that you are referencing this symbol from. Presumably your package is using some special definition of this symbol, instead of the MACRO that it usually is.

Christopher
Thanks Christopher. Upon looking closer, __imp__htonl is part of a library already on the machine. I simlpy added: "#pragma comment(lib, "Ws2_32.lib")" to the wrapper header and it works!
TomO
A: 

I ran into this error when I compiled against a library and then changed the library before linking. Make sure your headers are the same ones provided by your library (not copied from another architecture, etc). Of course, make sure you're linking against ws2_32.lib (-lws2_32 for mingw/gcc).

Additionally, if you are using GCC/mingw you may want to take a look at this: http://stackoverflow.com/questions/2033608/mingw-linker-error-winsock/2033632#2033632

wickedchicken