Linker LNK2019 error when dynamically linking Boost 1.51.0 in VS2010

I use boost libraries installed by the BoostPro Computing installer. I use VS 2010 on a 64-bit Windows 7 machine. I want to link dynamically dynamically, so I selected the first two parameters in the installer (multi-threaded debugging of the DLL and multi-threaded DLL, I believe that they were called). An example of some installed libs:

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

When linking to boost in my project, I also definitely defined BOOST_ALL_DYN_LINK . I specifically use the filesystem toolkit.

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

 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, they are quickly followed 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) 

Should auto-link.hpp take care of my link for me? I'm not specifically asking for something to be associated with the project, because the automatic linker seems to identify everything correctly. So, how am I missing this? They are also declared dllimport , so shouldn't the linker leave them alone and expect them to be detected at runtime?

Thanks!

UPDATE . I decided to dive into the second linker error. This basically suggests that he cannot find the destructor for the path class. After running dumpbin in 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 does not match what the linker is looking for, here's what:

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

Note that the linker is looking for a version of the DLL import, but the library itself does not seem to provide it ... not sure where to go from here, but this seems like important information!

+4
source share
3 answers

Assuming you have these .libs that have already been compiled, you need to make sure that the .lib files are in the library path (see VC ++ Directories-> library path).

The compiler will put the link to the DLL at compile time, using .lib to find the correct entry points, etc., so that they can load efficiently when the EXE / DLL starts at run time.

The runtime detection type of the DLL you are talking about requires code like LoadLibrary + GetProcAddress, which Boost does not support.

(Static binding actually puts the code from the statistically compiled .lib code into your DLL / EXE.)

EDIT: Also, check that you are using the correct .lib files for your archiving, for example. 32-bit or 64-bit. This will result in a similar error with signatures.

 dumpbin /headers 

will tell you what type of "machine" .lib is created for (the first part of dumpbin output).

+4
source

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

+5
source

There is (from your unresolved list) a difference in the call. This will cause the characters to not match. I found that 1.54.0 will not compile all libraries if you try to compile with other than _cdecl as a calling convention in Windows. Windows loves a lot of different calling conventions and they won’t match (_cdecl / Gd, __stdcall / Gz, __FASTCALL / Gr) Also, at least in 1.54.0 I noticed that some libraries require wchar_t to be considered as built-in type (VS VS / Zc: wchar_t option) (e.g. boost: log library). This will also cause unresolved errors since wchar_t does not match the short value in this case.

+1
source

Source: https://habr.com/ru/post/1437656/


All Articles