Weird LNK 2019 on a VS 2005 ported dll
1>stdafx.obj : error LNK2019: unresolved external symbol "void * __cdecl operator new(unsigned int,struct std::_DebugHeapTag_t const &,char *,int)" (??_U@YAPAXIABU_DebugHeapTag_t@std@@PADH@Z) referenced in function "public: char * __cdecl std::_DebugHeapAllocator<char>::allocate(unsigned int,void const *)" (?allocate@?$_DebugHeapAllocator@D@std@@QAAPADIPBX@Z)
1>stdafx.obj : error LNK2019: unresolved external symbol "struct std::_DebugHeapTag_t const & __cdecl std::_DebugHeapTag_func(void)" (?_DebugHeapTag_func@std@@YAABU_DebugHeapTag_t@1@XZ) referenced in function "public: char * __cdecl std::_DebugHeapAllocator<char>::allocate(unsigned int,void const *)" (<?allocate@?$_DebugHeapAllocator@D@std@@QAAPADIPBX@Z>)
Recently during a project upgrade from Visual Studio.NET 2003 to VS.NET 2005 i came across the above link error. The app is a normal dll that used CRT to do its stuff. This error occurs only in debug mode. The release mode compiled without any issues.
The VS.NET 2003 original project is not mine so i didn't know a lot about the settings. I decided to check the configuration and settings that the app was being built with.
The issue turned out to be the inclusion of 'libcmt.lib' in the debug mode. The debug version of libcmt is 'libcmtd.lib'. I changed the settings to include libcmtd.lib and removed the '/NODEFAULTLIB' that was specified. Still there were error messages as if libcmt was also included. I then had to explicitly ignore 'libcmt'. Things built properly from then
A couple of interesting things about this -
1) libcmt is not included directly. It comes from a static lib that's referred by the dll. ( Added on Aug 10 : The above statement is incorrect. Thanks to hmm for pointing this out.I will update here once i find out the actual reason)
2) VS 2003 didn't complain.