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 ?
To fix this issue, add the /NOENTRY option to the link command. This error can occur if you use incorrect /SUBSYSTEM or /ENTRY settings in your project. For example, if you write a console application and specify /SUBSYSTEM:WINDOWS, an unresolved external error is generated for WinMain .
So when we try to assign it a value in the main function, the linker doesn't find the symbol and may result in an “unresolved external symbol” or “undefined reference”. The way to fix this error is to explicitly scope the variable using '::' outside the main before using it.
__CxxFrameHandler4 indicates that the library is building with the VS 2019 x64 toolset (19.20 - 19.28), but is being linked against an older version of the Visual C++ Runtime.
Answer. Unresolved external references occur when the symbol for a function or global variable is referenced in a program, but none of the object files or libraries specified in the link step contain a definition for that symbol.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With