Windows API binding

I used the ITK library . When I wrote a sample program using this library, I got linker errors. As we can see, all the "unresolved" characters are Windows API functions, and these window API functions were used by the ITK library, and not my program.

Error 1 error LNK2019: unresolved external symbol _SnmpUtilVarBindFree@4 referenced in function "int __cdecl gdcm::GetMacAddrSys(unsigned char *)" ( ?GetMacAddrSys@gdcm @@ YAHPAE@Z ) C:\Projects\sampleProject\bin\itkgdcm.lib(gdcmUtil.obj) Error 2 error LNK2019: unresolved external symbol _SnmpUtilOidNCmp@12 referenced in function "int __cdecl gdcm::GetMacAddrSys(unsigned char *)" ( ?GetMacAddrSys@gdcm @@ YAHPAE@Z ) C:\Projects\sampleProject\bin\itkgdcm.lib(gdcmUtil.obj) Error 3 error LNK2019: unresolved external symbol _SnmpUtilOidCpy@8 referenced in function "int __cdecl gdcm::GetMacAddrSys(unsigned char *)" ( ?GetMacAddrSys@gdcm @@ YAHPAE@Z ) C:\Projects\sampleProject\bin\itkgdcm.lib(gdcmUtil.obj) Error 4 error LNK2019: unresolved external symbol _WSAStartup@8 referenced in function "int __cdecl gdcm::GetMacAddrSys(unsigned char *)" ( ?GetMacAddrSys@gdcm @@ YAHPAE@Z ) C:\Projects\sampleProject\bin\itkgdcm.lib(gdcmUtil.obj) Error 5 error LNK2019: unresolved external symbol __imp__UuidCreate@4 referenced in function "private: static bool __cdecl gdcm::Util::GenerateUUID(unsigned char *)" ( ?GenerateUUID@Util @ gdcm@ @ CA_NPAE@Z ) C:\Projects\sampleProject\bin\itkgdcm.lib(gdcmUtil.obj) Error 6 error LNK2019: unresolved external symbol _gethostbyname@4 referenced in function "private: static class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __cdecl gdcm::Util::GetIPAddress(void)" ( ?GetIPAddress@Util @ gdcm@ @ CA?AV?$basic_string@DU ?$char_traits@D @ std@ @ V?$allocator@D @ 2@ @ std@ @XZ) C:\Projects\sampleProject\bin\itkgdcm.lib(gdcmUtil.obj) Error 7 error LNK2019: unresolved external symbol _gethostname@8 referenced in function "private: static class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __cdecl gdcm::Util::GetIPAddress(void)" ( ?GetIPAddress@Util @ gdcm@ @ CA?AV?$basic_string@DU ?$char_traits@D @ std@ @ V?$allocator@D @ 2@ @ std@ @XZ) C:\Projects\sampleProject\bin\itkgdcm.lib(gdcmUtil.obj) Error 8 error LNK2019: unresolved external symbol _WSACleanup@0 referenced in function "private: static class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __cdecl gdcm::Util::GetIPAddress(void)" ( ?GetIPAddress@Util @ gdcm@ @ CA?AV?$basic_string@DU ?$char_traits@D @ std@ @ V?$allocator@D @ 2@ @ std@ @XZ) C:\Projects\sampleProject\bin\itkgdcm.lib(gdcmUtil.obj) 

These errors caused me several questions. For some of them, I think I know the answers, but I need confirmation if I'm right or wrong.

  • These Windows API functions are used in gdcmUtil.cpp (because it says gdcmUtil.obj). So, the compiler compiles gdcmUtil.cpp (say) gdcmUtil.asm, and it compiles the assembler in gdcmUtil.obj. Since when compiling the library we do not generate any exe files. These * .obj files are not associated with other * .obj. Thus, the Windows API characters are still external characters for this module and therefore remain unresolved. Right?

  • Who is generating the * .LIB file? I mean, the compiler generates a * .s file, and Assembler generates a * .obj file, and we do not use the linker. So where did we get the * .lib file? Who packed all * .obj files into a * .lib file?

  • How are the Windows API applications compiled (C programs using the Windows API)? I mean, because of its stand-alone applications, how are these WIN32 API characters resolved? I guess I wrote such a program, can someone tell me what I need to successfully create the application?

  • I know that the Windows API is implemented in the kernel32.dll, gdi32.dll, user32.dll file (which, in turn, can import some other dlls, such as wsock32.dll for the network API, etc.), but the question is is how to use these functions in the Windows API functions in a C program. I mean how to dynamically bind to these DLLs

  • In my quest to find the answer to my Linker error problem. I found that I should add wcock32.lib (for WinSock 1.1) or ws2_32.lib (for WinSock 2) or snmpapi.lib to enter Linker.

    • Since when is the Windows API statically linked?
    • Ever since the Windows API is delivered in static libraries (* .lib files)?
    • In which directory can all these strange * .lib files be found?
  • Now, is there an alternative solution other than adding * .lib files to the linker input files? because when I use some new ITK library function, I get a new linker error. I have to find Google in which the * .lib file belongs to this particular character (api window function), and then add this * .lib file to my linker input. It drives me crazy! Is there any reasonable way?

+4
source share
1 answer
  • Yes, that's right.
  • Who is generating the .lib file? A static library is usually generated by the lib utility. A library for a dll usually generated by the linker.
  • You allow Windows characters by referencing the libraries you need.
  • Again, contacting the appropriate library (for example, kernel32.lib, gdi32.lib and user32.lib for the three DLLs you mentioned).
  • It is not statically connected. You are contacting the library. In the case of a DLL (such as the ones listed above), the linker uses this to embed an entry in an executable file that tells the loader which DLL to use to resolve these characters. The .lib files are located in the lib subdirectory wherever you installed the SDK (usually something like C:\Program Files\Microsoft SDKs\Windows\v6.0A ). Typically, the SDK installer will add where necessary, so you do not need to explicitly specify this directory when linking to the line command or inside Visual Studio.
  • There are several, although one can doubt whether they are really improving. One possibility is to use a pragma to tell the linker to use a specific library:

    #pragma comment (lib, "ws2_32.lib")

This is especially useful in the header if it uses library-specific functions.

+3
source

All Articles