I was trying to debug a linking error LNK2019: unresolved external symbol. In order to so, I tried to list all the symbols in the library that is supposed to contain that symbol. However, I have two questions:
1) First, I am confused about how to read demangled symbol in this form:
type __cdecl <SYMBOL_NAME> (<X>)
Specifically, I was wondering what is the meaning of X and what is its importance? Also, can SYMBOL_NAME and X being swapped cause a linking error?
For example, here is a (demangled) definition of the symbol in the library:
void __cdecl boost::filesystem::path_traits::convert(char const * __ptr64,char const * __ptr64,class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > & __ptr64,class std::codecvt<wchar_t,char,int> const & __ptr64) (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 &))
Here is the linking error:
error LNK2019: unresolved external symbol "__declspec(dllimport) void __cdecl boost::filesystem3::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_void __cdecl boost::filesystem3::path_traits::convert(char const * __ptr64,char const * __ptr64,class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > & __ptr64,class std::codecvt<wchar_t,char,int> const & __ptr64) referenced in function "public: __cdecl boost::filesystem3::path::path<char const [4]>(char const (&)[4],void *)" (??$?0$$BY03$$CBD@path@filesystem3@boost@@QEAA@AEAY03$$CBDPEAX@Z)
You can see that the unresolved symbol and the existing symbol have their SYMBOL_NAME and X swapped.
2) Does anybody have any ideas on how to resolve the error listed above by any chance?
Any help will be greatly appreciated!
It seems like there's some mismatch between the boost dll you are linking against and the boost header file you are compiling against. i.e. your header file defines a filesystem3 namespace for which there are no symbols in the dll.
According to the Boost.FileSystem docs, the most likely scenario is your headers are from boost version 1.46 or 1.47 where filesystem v2 and v3 are both supported, but v3 is the default, while your dll is for boost 1.48 or higher, at which point v2 is no longer included and the v3 is the default (with no dedicated filesystem3 namespace).