Erreur de liaison lors de la compilation d'une ancienne bibliothèque STD et d'un SDK Windows

J'ai un ancien projet compilé dans VS2005 (malheureusement). Il doit rester dans VS2005 afin qu'il puisse se lier correctement à un autre processus qui a le VS2005 CRT, MFC, etc.Erreur de liaison lors de la compilation d'une ancienne bibliothèque STD et d'un SDK Windows

Maintenant, j'ai besoin de compiler ce projet dans VS2015, en utilisant l'ancien jeu d'outils VS2005.
J'ai remplacé les répertoires VC++ du projet par les anciens dossiers de tous les en-têtes et libérations STD et Windows SDK (répertoires Inclure, Répertoires de référence, Répertoires de bibliothèques, Répertoires sources).

Cette astuce utilisée pour fonctionner correctement tout en travaillant avec VS2010, mais sur VS2015 Je reçois des erreurs de lien étranges:

1>Project1.obj : error LNK2019: unresolved external symbol "void __stdcall `eh vector destructor iterator'(void *,unsigned int,unsigned int,void (__thiscall*)(void *))" ([email protected]@[email protected]) referenced in function "public: virtual void * __thiscall PluginInterface::`vector deleting destructor'(unsigned int)" ([email protected]@[email protected]) 
1>  1> 
1>StdAfx.obj : error LNK2001: unresolved external symbol "void __stdcall `eh vector destructor iterator'(void *,unsigned int,unsigned int,void (__thiscall*)(void *))" ([email protected]@[email protected]) 
1>  1> 
1>Project1.obj : error LNK2019: unresolved external symbol "void __cdecl operator delete(void *,unsigned int)" ([email protected]@Z) referenced in function [email protected]@@[email protected]XZ$0 
1>  1> 
1>Project1.obj : error LNK2019: unresolved external symbol "void __cdecl operator delete[](void *,unsigned int)" ([email protected]@Z) referenced in function "public: virtual void * __thiscall PluginInterface::`vector deleting destructor'(unsigned int)" ([email protected]@[email protected])

Pourquoi est-il pour cette mise en œuvre à la recherche intérieure du Deleter? Devrait-il obtenir l'implémentation à partir des en-têtes? Pourquoi cela fonctionnerait-il dans VS2010 et non VS2015?

Comment puis-je résoudre ce problème correctement?

Source

2017-06-29 Yochai Timmer

Avez-vous essayé de définir la propriété d'entrée de l'éditeur de liens pour ignorer les bibliothèques par défaut? – Mahesh

Oui, et cela n'a fait qu'empirer les choses. Ces symboles manquaient encore avec un tas d'autres. –

Ce sont des fonctions d'aide générées automatiquement, Raymond Chen en parle dans [cet ancien billet de blog] (https://blogs.msdn.microsoft.com/oldnewthing/20040203-00/?p=40763). Leur nom a changé, maintenant préfixant "eh" à leur nom. Je suppose que cela a quelque chose à voir avec le nouveau comportement demandé pour le mot-clé * static * dans C++ 11. Pas quelque chose que vous pouvez éteindre, compiler sans/EH est à peine une solution de contournement, donc vous êtes à peu près foutu. –

Ainsi, après avoir lu beaucoup de rupture des changements que je Documentations trouve un drapeau qui peut supprimer ces nouveaux C++ 14 delete implémentations here, sous Placement nouveau et supprimer. L'ajout de l'indicateur /Zc:sizedDealloc- supprime les implémentations manquantes delete() de l'opérateur.
Propriétés du projet -> Propriétés de configuration -> C/C++ -> ligne de commande ->/Zc: sizedDealloc-

vous pouvez revenir à l'ancien comportement en utilisant l'option du compilateur /Zc: sizedDealloc -. Si vous utilisez cette option, les fonctions de suppression à deux arguments n'existent pas et n'entraîneront pas de conflit avec votre opérateur de suppression .

Pour l'erreur eh vector destructor iterator j'ai opened a separate question et answered it there.

Source

2017-07-03 08:37:50

Erreur de liaison lors de la compilation d'une ancienne bibliothèque STD et d'un SDK Windows

Répondre

Questions connexes