Linker error LNK2019 when linking Boost 1.51.0 dynamically in VS2010

Question

I'm using the boost libraries as installed by the BoostPro Computing installer. I'm using VS 2010 on a Windows 7 64-bit machine. I want to link to boost dynamically, so I selected the first two options in the installer (Multithreaded Debug DLL and Multithreaded DLL, I believe they were called). An example of some installed libs are:

boost_bzip2-vc100-mt-1_51.lib
boost_bzip2-vc100-mt-gd-1_51.lib

When linking to boost in my project, I also made sure to define BOOST_ALL_DYN_LINK. I'm specifically using the filesystem toolset.

When I turn on BOOST_LIB_DIAGNOSTIC I see the following messages in the build output:

1>  Linking to lib file: boost_filesystem-vc100-mt-gd-1_51.lib
1>  Linking to lib file: boost_system-vc100-mt-gd-1_51.lib

However, those are quickly followed up by:

1>main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const __thiscall boost::filesystem::path::string(void)const " (__imp_?string@path@filesystem@boost@@QBE?BV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ) referenced in function _main
1>main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall boost::filesystem::path::~path(void)" (__imp_??1path@filesystem@boost@@QAE@XZ) referenced in function _main
1>main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) class boost::filesystem::path __cdecl boost::filesystem::detail::unique_path(class boost::filesystem::path const &,class boost::system::error_code *)" (__imp_?unique_path@detail@filesystem@boost@@YA?AVpath@23@ABV423@PAVerror_code@system@3@@Z) referenced in function "class boost::filesystem::path __cdecl boost::filesystem::unique_path(class boost::filesystem::path const &)" (?unique_path@filesystem@boost@@YA?AVpath@12@ABV312@@Z)
1>main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static class std::codecvt<wchar_t,char,int> const & __cdecl boost::filesystem::path::codecvt(void)" (__imp_?codecvt@path@filesystem@boost@@SAABV?$codecvt@_WDH@std@@XZ) referenced in function "public: __thiscall boost::filesystem::path::path<char const [20]>(char const (&)[20],void *)" (??$?0$$BY0BE@$$CBD@path@filesystem@boost@@QAE@AAY0BE@$$CBDPAX@Z)
1>main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) void __cdecl boost::filesystem::path_traits::convert(char const *,char const *,class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > &,class std::codecvt<wchar_t,char,int> const &)" (__imp_?convert@path_traits@filesystem@boost@@YAXPBD0AAV?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@ABV?$codecvt@_WDH@5@@Z) referenced in function "void __cdecl boost::filesystem::path_traits::dispatch<class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > >(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > &,class std::codecvt<wchar_t,char,int> const &)" (??$dispatch@V?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@@path_traits@filesystem@boost@@YAXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAV?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@4@ABV?$codecvt@_WDH@4@@Z)
1>main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) class boost::system::error_category const & __cdecl boost::system::generic_category(void)" (__imp_?generic_category@system@boost@@YAABVerror_category@12@XZ) referenced in function "void __cdecl boost::system::`dynamic initializer for 'posix_category''(void)" (??__Eposix_category@system@boost@@YAXXZ)
1>main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) class boost::system::error_category const & __cdecl boost::system::system_category(void)" (__imp_?system_category@system@boost@@YAABVerror_category@12@XZ) referenced in function "void __cdecl boost::system::`dynamic initializer for 'native_ecat''(void)" (??__Enative_ecat@system@boost@@YAXXZ)

Shouldn't the auto-link.hpp be taking care of my linking for me? I'm not specifically requesting anything be linked to the project because the auto linker appears to be identifying everything correctly. So how is it that I'm missing these things? Also, they're declared as dllimport, so shouldn't the linker be leaving them alone and expect them to be discovered at runtime?

Thanks!

UPDATE: I decided to dive in on the second linker error. It's basically saying that it can't find the destructor for the path class. After running dumpbin on the filesystem library, I noticed that this line is in the file:

??1path@filesystem@boost@@QEAA@XZ (public: __cdecl boost::filesystem::path::~path(void))

But this obviously doesn't match with what the linker is looking for, which is this:

"__declspec(dllimport) public: __thiscall boost::filesystem::path::~path(void)" (__imp_??1path@filesystem@boost@@QAE@XZ)

Notice that the linker is looking for a DLL-import version, but the library itself doesn't seem to be providing one... not sure where to go from here, but it seems like important information!

Answer 1

For me, this was because the "treat wchar_t as built-in type" option was set to false, so that wchar_t was compiled as unsigned short.

Answer 2

Assuming you have those .lib already compiled you need to make sure that the .lib files are in the Library path (look VC++ Directories->Library path).

The compiler will place a link to the DLLs at compile time, using the .lib to discover the correct entry points etc, so they can be loaded efficiently when the EXE/DLL starts up at run-time.

The type of runtime DLL discovery you're talking about requires LoadLibrary + GetProcAddress type code, which Boost doesn't support.

(Static linking actually puts code from a statcially compiled .lib code into your DLL/EXE.)

EDIT: Also, check you're using the correct .lib files for your archicture, e.g. 32-bit or 64-bit. That would cause a similar error with the signatures.

dumpbin /headers 

will tell you which 'machine' type the .lib has been built for (the first section of the dumpbin output).