Boost Linker Error: unresolved external symbol - boost

I built boost latest version (64 bit, msvc-10.0). When using the libraries with my project getting following linker error:
error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::system_category(void)" (?
Things checked:
1. Libraries are present in the path specified
2. Built 64-bit boost library
3. Using latest boost headers, etc..
Any suggestions?

I've experienced the same problem when using some header-only boost library. The problem is some libraries are themselves header-only, but they depend on boost.system which need be linked against your program.

Related

Using zlib in Visual C++ project

I've been struggling to compile my Visual C++ 2010 project with dependency of Zlib. I've got source code that worked on Linux and Mac OS X. Here's, where I have linker errors:
error LNK2019: unresolved external symbol _inflate#8 referenced in function...
error LNK2019: unresolved external symbol _inflateInit2_#16 referenced in function...
error LNK2019: unresolved external symbol _deflate#8 referenced in function...
error LNK2019: unresolved external symbol _deflateInit2_#32 referenced in function...
I've been finding solution for few days now, trying compiling Zlib different ways, but it is clear that I've missed something. Very similar question has been answered here, but not clearly enough for amateur like me. I would need step-by-step guide how to get it to work.
Thank you in advance.
If you have static libraries after building the Zlib, point them in your project at this location.Project properties -> Linker -> Input -> Additional dependencies. Give the absolute path.

boost.log errors linking statically

I'm getting the following (and many more) errors when attempting to link my project statically with boost.log on MSVC 10.0:
1>libboost_log-vc100-mt-gd-1_53.lib(attribute_name.obj) : error
LNK2001: unresolved external symbol "**__declspec(dllimport)** public:
__thiscall std::_Container_base::~_Container_base(void)" (__imp_??1_Container_base#std##QAE#XZ)
1>libboost_log-vc100-mt-gd-1_53.lib(text_file_backend.obj) : error
LNK2001: unresolved external symbol "**__declspec(dllimport)** public:
__thiscall std::_Container_base::~_Container_base(void)" (__imp_??1_Container_base#std##QAE#XZ)
Note that the project is linking also to boost system, filesystem, and thread libraries.
1> Searching ../lib/\libboost_system-vc100-mt-gd-1_53.lib:
1> Searching ../lib/\libboost_date_time-vc100-mt-gd-1_53.lib:
1> Searching ../lib/\libboost_regex-vc100-mt-gd-1_53.lib:
1> Searching ../lib/\libboost_thread-vc100-mt-gd-1_53.lib:
1> Searching ../lib/\libboost_chrono-vc100-mt-gd-1_53.lib:
1> Searching ../lib/\libboost_log-vc100-mt-gd-1_53.lib:
1> Searching ../lib/\libboost_filesystem-vc100-mt-gd-1_53.lib:
My project does not define the BOOST_ALL_DYN_LINK or BOOST_LOG_DYN_LINK macros, so I was not expecting to see the __declspec signatures, which I am thinking is the ultimate problem. Am I missing something required to properly link this library statically?
Update
I removed precompiled headers on my project and performed a "clean", and everything linked fine. Is it possible that precompiled headers were somehow causing the project to link statically to CRT?
You may need link log_setup firstly and then log before filesystem and so on, this was boost link code in my CMakeLists.txt:
set(USED_BOOST_LIBS ${Boost_LOG_SETUP_LIBRARY} ${Boost_LOG_LIBRARY}
${Boost_FILESYSTEM_LIBRARY}
${Boost_SYSTEM_LIBRARY} ${Boost_DATE_TIME_LIBRARY}
${Boost_THREAD_LIBRARY} ${Boost_REGEX_LIBRARY}
)
...
target_link_libraries(myexe ${USED_BOOST_LIBS})
It works fine with me both on MSVC 14.0 and gcc 4.8.You can try it.

Linking the Windows API

I was using a ITK library. When I wrote a sample program using this library, I've got following linker errors. As we can see these all "unresolved" symbols are Windows API functions and these windows API functions were used by 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 have raised few questions in my mind. 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, compiler compiles gdcmUtil.cpp to (say)gdcmUtil.asm and it is assembler assembles it to gdcmUtil.obj. Since while compiling the library we are not generating any exe files. These *.obj files aren't linked against any other *.obj. So, windows API symbols are still external symbols for that module and thus left unresolved. Right?
Who is generating the *.LIB file? I mean compiler is generating *.s file and Assembler is generating *.obj file and we are not using linker. So, from where did we get *.lib file? Who packed all *.obj files to a *.lib file?
How are Windows API applications (programs that are written in C and use Windows API) are compiled? I mean, because its a standalone applications how are these WIN32 API symbols resolved? Assuming, I've written such program can anyone tell me what do I need to sucessfully build application?
I know that Windows API is implemented in kernel32.dll, gdi32.dll, user32.dll (which may in turn import some other dlls like wsock32.dll for networking API etc.) but the question is How to use these functions in Windows API functions in a C program. I mean how to dynamically link against these DLLs
In my quest to find answer to my problem of Linker errors. I discovered that I must add wsock32.lib (for WinSock 1.1) or ws2_32.lib(for WinSock 2) or snmpapi.lib to Linker Input.
Since when Windows API is being statically linked?
Since when windows API is being shipped in static libraries (*.lib files)?
In which directory can I find all these strange *.lib files?
Now, Is there any alternative solution other than adding *.lib files to linker input files? because when ever I use some new ITK library function, I get a new linker error. I've to Google to find in which *.lib file this specific symbol (window api function) belongs to then add that *.lib file to my linker input. Its driving me crazy! Is there any sane way?
Yes, that's right.
Who is generating what .lib file? A static library is normally generated by the lib utility. A library for a dll is normally generated by the linker.
You resolve Windows symbols by linking with the right libraries.
Again, by linking against the appropriate library (e.g., kernel32.lib, gdi32.lib and user32.lib for the three DLLs you mentioned).
It's not statically linked. You link against the library. In the case of a library for a DLL (such as those listed above) the linker uses that to embed a record into the executable that tells the loader which DLL to use to resolve those symbols. The .lib files are in the lib subdirectory of wherever you installed the SDK (typically something like C:\Program Files\Microsoft SDKs\Windows\v6.0A. Normally the SDK installer will add those where necessary so you don't have to explicitly specify that directory when linking from the command line or within Visual Studio.
There are a few, though it's open to question whether they're really an improvement. One possibility is to use a pragma to tell the linker to use a particular library:
#pragma comment(lib, "ws2_32.lib")
This is particularly useful in a header if it uses functions that depend on a particular library.

linking with boost unresolved extern link error

Visual Studio 2005
I am linking with boost libraries release 1_33_1.
I keep getting this link error.
libboost_thread-vc80-mt-sgd-1_33_1.lib(once.obj) :error LNK2001: unresolved external symbol "public: void __thiscall std::_String_base::_Xran(void)const " (?_Xran#_String_base#std##QBEXXZ)
Does anyone have any suggestions?
Many thanks,
Edit ======
After recompiling the boost libraries using these switches:
C:\boost_1_42_0>bjam --build-dir=d:\boost_1_42 --build-type-complete --toolset=msvc-8.0 address-model=32 architecture=x86
I am getting some of the following errors:
1>msvcrtd.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info##AAEAAV0#ABV0##Z) already defined in LIBCMTD.lib(typinfo.obj)
1>msvcrtd.lib(MSVCR80D.dll) : error LNK2005: __wassert already defined in LIBCMTD.lib(wassert.obj)
Anyone have any ideas?
Many thanks,
First of all you don't have to set address-model and architecture explicitly if building 32 bit. Also your call has an error: --build-type-complete should be --build-type=complete. If I'm not wrong your call builds absolutely all libs, including filesystem, regex etc.
Obviously you need boost::thread only, so I would recommend to try this call:
C:\boost_1_42_0>bjam --build-dir=d:\boost_1_42 --build-type=complete --toolset=msvc-8.0 --with-thread
But I don't think that will solve your prob but you could give it a try.
My guess is that you somehow mixed /MD and /MT in the project settings.
See these links: First, second
What is probably happening is that your project is linking to the static debug version of the C++ runtime, which causes the static debug boost thread library to be linked and is also linking to another static library which was dynamically linked to the C++ runtime.
The sgd tag in libboost_thread-vc80-mt-sgd-1_33_1.lib means that the boost thread library you're linking with was built against the static debug version of the C++ runtime.

CUDA: Getting linking error only in device emulation mode

I am compiling a dll which goes just fine unless I use the -deviceemu mode.
In this case I get several of the following linking errors:
CUDAKernel_ColourHist.obj : error LNK2019: unresolved external symbol
___cudaMutexOperation#4 referenced in function ___uAtomicAdd
1>CUDAKernel_1.obj : error LNK2001:
unresolved external symbol
___cudaMutexOperation#4 1>CUDAKernel_2.obj : error LNK2001:
unresolved external symbol
___cudaMutexOperation#4
Which led me to believe perhaps I wasn't linking the correct files, but I believe I am. I am using Visual Studio and any help woud be appreciated.
Fixed, I was using an older version of the libraries, linking with the newer libraries fixed the problem.

Resources