C++ link error: missing Orphan_all(), Container_base12(), Xlength_error

    Jun 10 2013 | 11:05 am
    Hi all. I recently incorporated more C++ into my Max external dp.kinect. The latest round of inclusion is now causing linker errors when linked against the Max private libraries (the default behavior). I use Microsoft Visual C++ 2010 Express. Below are those errors.
    Any ideas on how to circumnavigate this? Here is what I have done and learned so far:
    1>KinectAudioStream.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl std::_Xlength_error(char const *)" (__imp_?_Xlength_error@std@@YAXPBD@Z)
    1>KinectAudioStream.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __thiscall std::_Container_base12::_Orphan_all(void)" (__imp_?_Orphan_all@_Container_base12@std@@QAEXXZ)
    1>KinectAudioStream.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Container_base12::~_Container_base12(void)" (__imp_??1_Container_base12@std@@QAE@XZ)
    1>KinectAudioStream.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Container_base12::_Container_base12(void)" (__imp_??0_Container_base12@std@@QAE@XZ)

    • Jul 25 2013 | 10:29 am
      I continue to experience this difficulty with Max SDKs 6.1.1 and 6.1.3 both with VC Express 2012.
      I suspect it is related to having some C++ objects which I call into. Only when I compile against the Microsoft MSVCRT does it compile. I am so far unable to use the runtimes shipped with Max.
    • Jul 25 2013 | 1:37 pm
      It sounds like you have probably diagnosed this correctly. FWIW, in my own private externals I link statically to the MS runtime and have not had any problems doing things that way.
      - .. --
    • Jul 25 2013 | 2:07 pm
      Ok. Good to hear my approach is similar to that of an experienced Max dev like yourself is doing.
      For those reading...it is possible to successfully link against the MS C DLL runtime (/MD) and use the preprocessor define MAXAPI_USE_MSCRT. However, this could cause a scenario where someone using the external might need to download the MS C runtime. Its a small runtime, but is a potential extra step.
      Instead, I now statically link using: /MT and MAXAPI_USE_MSCRT Compiles, runs, no errors, no runtime download.
      There are some esoteric caveats for statically linking. Microsoft write to some of the issues here http://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.110).aspx
    • Nov 03 2013 | 1:55 pm
      I am really glad you figured this out already and I stumbled on this post. I was pulling hairs for several hours going trough all the VS settings trying to figure out why the release build generated linker errors and the debug didn't.
      In addition to your instructions I also had to remove the libcmt.lib from the ignored libraries.
    • Nov 03 2013 | 1:55 pm
      (removed double post)