2

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!

Ben N.
  • 1,217
  • 2
  • 9
  • 9
  • The main difference I see is the presence of `__ptr64` in the first and not in the second. That sounds like the library is compiled for 64 bit but the program that you're trying to compile is not? – sfjac Mar 24 '16 at 22:39
  • Nothing is "swapped", yay for unreadable template error messages. The one you need is a 64-bit function in the boost::filesystem namespace, the one you found is a 32-bit function in the boost::filesystem3 namespace. Wrong library. – Hans Passant Mar 24 '16 at 23:06
  • Thank you very much for your answers @sfjac and Hans Passant! Do you know how I can make the code that I am trying to compile to use 64-bit function? (FYI: I made sure that the linker is linking against the correct library.) Do I have to somehow explicitly use the "char const * __ptr64" type in the source code? – Ben N. Mar 24 '16 at 23:36
  • 1
    P.S. I am also using a 64-bit machine. Therefore, I assume type pointers default to __ptr64, as it is stated here: https://msdn.microsoft.com/en-us/library/aa985900.aspx – Ben N. Mar 24 '16 at 23:45
  • 1
    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. when you compile you're finding the filesystem v3, but the dll was built with v2. You could try defining BOOST_FILESYSTEM_VERSION 2 when you build and see if that helps. more details in the [Boost.Filesystem docs](http://www.boost.org/doc/libs/1_46_0/libs/filesystem/v3/doc/index.htm) – lobudge Mar 24 '16 at 23:58
  • @Iobudge Thank you for your catch. It turns out I included the wrong headers for the Boost library. More info: – Ben N. Mar 25 '16 at 00:48
  • I included headers for the older version of the library (1.47 instead of 1.56). The older version had two version of headers defined for filesystem: v2 and v3. However, in the newer release of Boost v3 version turned into the default version and v2 was completely deleted, as far as I can see from headers (i.e. filesystem3 namespace turned into just filesystem). – Ben N. Mar 25 '16 at 00:54
  • @lobudge. Please create a new answer, so that I can mark it as correct. – Ben N. Mar 25 '16 at 00:55
  • @Ben - Thanks - I added an answer. I'm new on here, but I wonder if it makes sense to edit the question - since my answer does not address the question: "How to read demangled symbols". – lobudge Mar 25 '16 at 04:22

1 Answers1

2

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).

lobudge
  • 171
  • 4