web-dev-qa-db-fra.com

Incompatibilité détectée pour 'RuntimeLibrary'

J'ai téléchargé et extrait Crypto ++ dans C:\cryptopp. J'ai utilisé Visual Studio Express 2012 pour construire tous les projets à l'intérieur (comme indiqué dans le readme), et tout a été construit avec succès. Ensuite, j'ai fait un projet de test dans un autre dossier et ajouté cryptolib comme dépendance. Après cela, j'ai ajouté le chemin d'inclusion afin que je puisse facilement inclure tous les en-têtes. Lorsque j'ai essayé de compiler, j'ai eu une erreur concernant les symboles non résolus.

Pour remédier à cela, j'ai ajouté C:\cryptopp\Win32\Output\Debug\cryptlib.lib pour lier des dépendances supplémentaires. Maintenant je reçois cette erreur:

Error   1   error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj    C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(cryptlib.obj)    CryptoTest
Error   2   error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj    C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(iterhash.obj)    CryptoTest
Error   3   error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj    C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(sha.obj) CryptoTest
Error   4   error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj    C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(pch.obj) CryptoTest
Error   5   error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj    C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(misc.obj)    CryptoTest
Error   6   error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj    C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(queue.obj)   CryptoTest
Error   7   error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj    C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(algparam.obj)    CryptoTest
Error   8   error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj    C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(filters.obj) CryptoTest
Error   9   error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj    C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(fips140.obj) CryptoTest
Error   10  error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj    C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(cpu.obj) CryptoTest
Error   11  error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj    C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(mqueue.obj)  CryptoTest

Je reçois aussi:

Error   12  error LNK2005: "public: __thiscall std::_Container_base12::_Container_base12(void)" (??0_Container_base12@std@@QAE@XZ) already defined in cryptlib.lib(cryptlib.obj)    C:\Data\Work\C++ VS\CryptoTest\CryptoTest\msvcprtd.lib(MSVCP110D.dll)   CryptoTest
Error   13  error LNK2005: "public: __thiscall std::_Container_base12::~_Container_base12(void)" (??1_Container_base12@std@@QAE@XZ) already defined in cryptlib.lib(cryptlib.obj)   C:\Data\Work\C++ VS\CryptoTest\CryptoTest\msvcprtd.lib(MSVCP110D.dll)   CryptoTest
Error   14  error LNK2005: "public: void __thiscall std::_Container_base12::_Orphan_all(void)" (?_Orphan_all@_Container_base12@std@@QAEXXZ) already defined in cryptlib.lib(cryptlib.obj)   C:\Data\Work\C++ VS\CryptoTest\CryptoTest\msvcprtd.lib(MSVCP110D.dll)   CryptoTest
Error   15  error LNK2005: "public: __thiscall std::locale::id::id(unsigned int)" (??0id@locale@std@@QAE@I@Z) already defined in cryptlib.lib(iterhash.obj) C:\Data\Work\C++ VS\CryptoTest\CryptoTest\msvcprtd.lib(MSVCP110D.dll)   CryptoTest
Warning 16  warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of other libs; use /NODEFAULTLIB:library   C:\Data\Work\C++ VS\CryptoTest\CryptoTest\LINK  CryptoTest
Error   17  error LNK1169: one or more multiply defined symbols found   C:\Data\Work\C++ VS\CryptoTest\Debug\CryptoTest.exe 1   1   CryptoTest

Le code que j'ai essayé de compiler était simple (je l'ai obtenu sur un autre site):

#include <iostream>
#include <string>
#include "sha.h"
#include "hex.h"
using namespace std;

string SHA256(string data) {
    byte const* pbData = (byte*) data.data();
    unsigned int nDataLen = data.size();
    byte abDigest[32];

    CryptoPP::SHA256().CalculateDigest(abDigest, pbData, nDataLen);

    return string((char*)abDigest);
}

int main(void) {

    return 0;
}

Une idée de comment réparer ça? Je n'ai vraiment besoin que de SHA-256 pour le moment, rien d'autre. J'utilise Windows 7 64 bits et j'ai téléchargé VS C++ aujourd'hui. Il devrait donc s'agir de la version la plus récente.

c++hashcompilationsha256crypto++
102
Momonga

(Ceci est déjà répondu dans les commentaires, mais comme il manque une réelle réponse, j'écris ceci.)

Ce problème se pose dans les versions les plus récentes de Visual C++ (les anciennes versions liaient généralement le programme en silence et il se plantait et se gravait au moment de l'exécution.) Cela signifie que certaines des bibliothèques que vous liez avec votre programme (ou même certaines des sources les fichiers contenus dans votre programme lui-même) sont utilisent différentes versions du CRT (la bibliothèque C RunTime.)

Pour corriger cette erreur, vous devez entrer dans votre Project Properties (et/ou celles des bibliothèques que vous utilisez), puis dans C/C++, puis Code Generation, et vérifiez la valeur de Runtime Library; cela devrait être exactement le même pour tous les fichiers et les bibliothèques que vous liez ensemble. (Les règles sont un peu plus souples pour la liaison avec des DLL, mais je ne vais pas entrer dans le "pourquoi" ni dans les détails ici.)

Il existe actuellement quatre options pour ce paramètre:

  1. Débogage multithread
  2. DLL de débogage multithread
  3. Version multithread
  4. DLL de version multithread

Votre problème particulier semble provenir du fait que vous avez lié une bibliothèque créée avec "Multithreaded Debug" (c'est-à-dire un CRT de débogage statique multithread statique) à un programme en cours de construction à l'aide du "Multithreaded Debug [~ # ~] dll [~ # ~ ] "(c’est-à-dire un CRT de débogage dynamique multithread). Vous devez modifier ce paramètre soit dans la bibliothèque, soit dans votre programme. Pour le moment, je suggère de changer cela dans votre programme.

Notez que, dans la mesure où les projets Visual Studio utilisent différents ensembles de paramètres de projet pour les versions de débogage et d'édition (et les versions 32/64 bits), vous devez vous assurer que les paramètres correspondent dans toutes ces configurations de projet.

Pour (certains) plus d'informations, vous pouvez voir ces (liées à partir d'un commentaire ci-dessus):

  1. Avertissement des outils de liens LNK4098 sur MSDN
  2. / MD,/ML,/MT,/LD (Utiliser la bibliothèque d'exécution) sur MSDN
  3. Les erreurs de construction avec VC11 Beta - la liaison des bibliothèques MTd avec les ex MDd échoue sur Bugzilla @ Mozilla

[~ # ~] update [~ # ~] : (Ceci est la réponse à un commentaire qui demande la raison pour laquelle autant d'attention doit être prise .)

Si deux morceaux de code que nous lions ensemble sont eux-mêmes liés et utilisent la bibliothèque standard, la bibliothèque standard doit être identique pour les deux, à moins que great deux codes interagissent et transmettent des données. En règle générale, je dirais que, dans presque toutes les situations, utilisez la même version du moteur d’exécution de la bibliothèque standard (en ce qui concerne le débogage/la publication, les threads et, bien entendu, la version de Visual C++, entre autres comme le débogage par l’itérateur, etc.).

La partie la plus importante du problème est la suivante: ayant la même idée de la taille des objets de chaque côté d’un appel de fonction.

Considérons par exemple que les deux morceaux de code ci-dessus s'appellent A et B. A est compilé contre une version de la bibliothèque standard et B contre une autre. Dans la vue de A, un objet aléatoire renvoyé par une fonction standard (par exemple, un bloc de mémoire, un itérateur ou un objet FILE ou autre) a une taille et une présentation spécifiques (rappelez-vous que la structure d'une structure est déterminée et corrigée). au moment de la compilation en C/C++.) Pour différentes raisons, B n’a pas la même idée de la taille/de la présentation des mêmes objets (cela peut être dû à des informations de débogage supplémentaires, à l’évolution naturelle des structures de données, etc.).

Maintenant, si A appelle la bibliothèque standard et récupère un objet, puis passe cet objet à B, et B touche cet objet de quelque manière que ce soit, il y a de fortes chances que B dérange cet objet (par exemple, écrit le mauvais champ ou après la fin de celui-ci, etc.)

Ce qui précède n'est pas le seul type de problèmes pouvant survenir. Les objets globaux ou statiques internes de la bibliothèque standard peuvent également causer des problèmes. Et il existe également des classes de problèmes plus obscures.

Cela devient parfois plus étrange lorsque vous utilisez des DLL (bibliothèque d'exécution dynamique) au lieu de libs (bibliothèque d'exécution statique).

Cette situation peut s’appliquer à n’importe quelle bibliothèque utilisée par deux éléments de code travaillant ensemble, mais la bibliothèque standard est utilisée par la plupart des programmes (sinon tous), ce qui augmente les risques de conflit.

Ce que j'ai décrit est évidemment une version allégée et simplifiée du gâchis réel qui vous attend si vous mélangez des versions de bibliothèque. J'espère que cela vous donne une idée de la raison pour laquelle vous ne devriez pas le faire!

213
yzt

J'ai téléchargé et extrait Crypto ++ dans C:\cryptopp. J'ai utilisé Visual Studio Express 2012 pour construire tous les projets à l'intérieur (comme indiqué dans le readme), et tout a été construit avec succès. Ensuite, j'ai fait un projet de test dans un autre dossier et ajouté cryptolib comme dépendance.

La conversion n'a probablement pas réussi. La seule chose qui a réussi est l’exécution de VCUpgrade. La conversion elle-même a échoué, mais vous ne le savez pas jusqu'à ce que vous rencontriez les erreurs que vous voyez. Pour certains détails, voir Visual Studio sur le wiki Crypto ++.

Une idée de comment réparer ça?

Pour résoudre vos problèmes, vous devez télécharger vs2010.Zip si vous souhaitez un lien statique d'exécution C/C++ (/MT Ou /MTd), Ou vs2010-dynamic.Zip si vous souhaitez lier dynamiquement le runtime C/C++ (/MT Ou /MTd). Les deux résolvent les échecs latents et silencieux produits par VCUpgrade.

vs2010.Zip , vs2010-dynamic.Zip et vs2005-dynamic.Zip sont construits à partir des dernières sources GitHub . Au moment de la rédaction de cet article (JUN 1 2016), c'est effectivement une version antérieure à Crypto ++ 5.6.4. Si vous utilisez les fichiers Zip avec un niveau bas Crypto ++, comme 5.6.2 ou 5.6.3, vous rencontrerez des problèmes mineurs.

Je suis conscient de deux problèmes mineurs. En premier lieu, renommez bench.cpp En bench1.cpp . Son erreur est soit:

  • C1083: Cannot open source file: 'bench1.cpp': No such file or directory
  • LNK2001: unresolved external symbol "void __cdecl OutputResultOperations(char const *,char const *,bool,unsigned long,double)" (?OutputResultOperations@@YAXPBD0_NKN@Z)

Le correctif consiste à (1) ouvrir cryptest.vcxproj Dans le bloc-notes, trouver bench1.cpp, Puis le renommer en bench.cpp. Ou (2) renommez bench.cpp En bench1.cpp Sur le système de fichiers. S'il vous plaît ne supprimez pas ce fichier.

Le deuxième problème est un peu plus délicat, car c’est une cible mouvante. Les dernières versions disponibles dans GitHub , comme les versions 5.6.2 ou 5.6.3, sont absentes. Les fichiers de classe manquants incluent HKDF (5.6.3), RDRAND (5.6.3), RDSEED (5.6.3), ChaCha (5.6.4), BLAKE2 (5.6.4), Poly1305 (5.6.4), etc.

Le correctif consiste à supprimer les fichiers source manquants des fichiers de projet Visual Studio car ils n'existent pas pour les versions de niveau inférieur.

Une autre option consiste à ajouter les fichiers de classe manquants à partir des sources les plus récentes, mais il pourrait y avoir des complications. Par exemple, beaucoup de sources dépendent subtilement des derniers config.h, cpu.h Et cpu.cpp. La "subtilité" est que vous ne réaliserez pas que vous obtenez une classe sous-performante.

BLAKE2 est un exemple de classe peu performante. config.h Ajoute la détection des temps de compilation ARM-32 et ARM-64. cpu.h Et cpu.cpp Ajoutent le temps d'exécution ARM, qui dépend de la détection du temps de compilation. Si vous ajoutez BLAKE2 sans les autres fichiers, aucune détection ne se produit. et vous obtenez une implémentation directe en C/C++ et vous ne réaliserez probablement pas que vous manquez l’occasion NEON, qui tourne autour de 9 à 12 cycles par octet, au lieu de 40 cycles par octet pour Vanilla C/C++.

3
jww

J'ai eu ce problème avec incompatibilité dans ITERATOR_DEBUG_LEVEL. Après tout, le problème du dimanche soir semblait aller pour le mieux, mais je suis resté dehors pendant un certain temps. Travailler dans de VS2017 IDE (Explorateur de solutions)), j’avais récemment ajouté/copié une référence de fichier source à mon projet (ctrl-glisser) depuis un autre projet. au niveau du fichier source, pas au niveau du projet - J'ai remarqué que, dans une configuration de version, _DEBUG était spécifié à la place de NDEBUG pour ce fichier source.

3
Jan

Le problème peut être résolu en ajoutant le CRT de msvcrtd.lib dans la bibliothèque de l'éditeur de liens. Parce que cryptlib.lib utilisait la version CRT de débogage.

0
abhijithkp