在VS2010中动态链接Boost 1.51.0时链接器错误LNK2019

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

对我来说，这是因为“将wchar_t视为内置类型”选项设置为false，因此wchar_t被编译为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, eg 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).

Answer 3

There is (from your unresolved list) a difference in calling convention. This will cause the symbols to not match. I've found that 1.54.0 will not compile all libraries if you try to compile with other than _ cdecl as the calling convention on Windows. Windows likes lots of different calling conventions, and they will not match ( _cdecl /Gd, __stdcall /Gz, __FASTCALL /Gr) Also, at least in 1.54.0 I've notice that some libraries require wchar_t to be treated as a built-in type (Windows VS option /Zc:wchar_t) (boost::log library for sure). This will also cause unresolved errors as a wchar_t does not match unsigned short in this case.