9

I have an old project that is compiled in VS2005 (Sadly). It has to remain in VS2005 so it can link properly to another process which has the VS2005 CRT,MFC, etc.

Now I need to compile this project in VS2015, using the old VS2005 toolset.
I've changed the project's VC++ directories to the old folders for all the STD and Windows SDK headers/libs (Include directories, Reference Directories, Library Directories, Source Directories).

This trick used to work fine while working with VS2010, but on VS2015 I'm getting some weird link errors:

1>Project1.obj : error LNK2019: unresolved external symbol "void __stdcall `eh vector destructor iterator'(void *,unsigned int,unsigned int,void (__thiscall*)(void *))" (??_M@YGXPAXIIP6EX0@Z@Z) referenced in function "public: virtual void * __thiscall PluginInterface::`vector deleting destructor'(unsigned int)" (??_EPluginInterface@@UAEPAXI@Z)
1>     1>
1>StdAfx.obj : error LNK2001: unresolved external symbol "void __stdcall `eh vector destructor iterator'(void *,unsigned int,unsigned int,void (__thiscall*)(void *))" (??_M@YGXPAXIIP6EX0@Z@Z)
1>     1>
1>Project1.obj : error LNK2019: unresolved external symbol "void __cdecl operator delete(void *,unsigned int)" (??3@YAXPAXI@Z) referenced in function __unwindfunclet$?getInstance@Project1@@SAPAV1@XZ$0
1>     1>
1>Project1.obj : error LNK2019: unresolved external symbol "void __cdecl operator delete[](void *,unsigned int)" (??_V@YAXPAXI@Z) referenced in function "public: virtual void * __thiscall PluginInterface::`vector deleting destructor'(unsigned int)" (??_EPluginInterface@@UAEPAXI@Z)

Why is it looking for this inner implementation of the deleter ? Should it be getting the implementation from the headers? Why would it work in VS2010 and not VS2015?

How can I fix this properly ?

Yochai Timmer
  • 48,127
  • 24
  • 147
  • 185
  • Have you tried setting the linker input property to ignore default libraries ? – Mahesh Jun 29 '17 at 13:46
  • Yes, and it only made it worse. Those symbols were stil missing along with a bunch of others. – Yochai Timmer Jun 29 '17 at 13:50
  • 1
    These are auto-generated helper functions, Raymond Chen talks about them in [this old blog post](https://blogs.msdn.microsoft.com/oldnewthing/20040203-00/?p=40763). Their name has changed, now prefixing "eh" to their name. I'd guess it has something to do with the new behavior demanded for the *static* keyword in C++11. Not something you can turn off, compiling without /EH is hardly a workaround so you are pretty much screwed. – Hans Passant Jul 02 '17 at 15:59
  • @HansPassant Thanks, that's a bit of info at least. I've narrowed it down to static stuff mostly, but there are other weird ones (like those operator deletes). Is there a hidden flag somewhere to force C99 ? Or to dismiss "Features" ? – Yochai Timmer Jul 02 '17 at 17:50

1 Answers1

8

So, after reading a lot of breaking changes documentations i found a flag that can suppress these new c++14 delete implementations here, under Placement new and delete.

Adding the flag /Zc:sizedDealloc- removes the missing operator delete() implementations.
Project properties -> Configuration Properties -> C/C++ -> Command Line -> /Zc:sizedDealloc-

you can revert to the old behavior by using the compiler option /Zc:sizedDealloc-. If you use this option, the two-argument delete functions don’t exist and won't cause a conflict with your placement delete operator.

For the eh vector destructor iterator error I've opened a separate question, and answered it there.

Yochai Timmer
  • 48,127
  • 24
  • 147
  • 185
  • Hi, i have same situation, like you but my error is `error LNK2001: unresolved external symbol ___std_terminate` How avoid this? – ilw Feb 04 '19 at 19:20