Erreur détectée pour 'RuntimeLibrary'.

Question

J'ai téléchargé et extrait Crypto++ en 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 j'ai 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. Quand j'ai essayé de compiler, j'ai eu une erreur à propos de 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 comprends 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 d'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;
}

Vous avez une idée de la façon de régler ce problème ? Je n'ai vraiment besoin que de SHA-256 pour le moment, rien d'autre. J'utilise Windows 7 64 bit, et j'ai téléchargé VS C++ aujourd'hui, donc ce doit être la dernière version.

Answer 1

(Cette question a déjà fait l'objet d'une réponse dans les commentaires, mais comme il n'y a pas de réponse concrète à cette question, nous avons décidé de ne pas y répondre. réponse Je suis en train d'écrire ceci.)

Ce problème se pose dans les nouvelles versions de Visual C++ (les anciennes versions se contentaient généralement de lier le programme de manière silencieuse et celui-ci se plantait au moment de l'exécution). Cela signifie que certaines des bibliothèques que vous liez avec votre programme (ou même certains des fichiers sources dans votre programme lui-même) sont en utilisant différentes versions de la CRT (la bibliothèque C RunTime).

Pour corriger cette erreur, vous devez vous rendre dans votre Project Properties (et/ou ceux des bibliothèques que vous utilisez), puis dans le fichier C/C++ entonces Code Generation et vérifier la valeur de Runtime Library ; cela devrait être exactement la même chose pour todo les fichiers et les bibliothèques que vous liez ensemble. (Les règles sont un peu plus souples pour lier avec des DLL, mais je ne vais pas entrer dans le "pourquoi" et dans plus de 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ée
4. DLL de libération multithread

Votre problème particulier semble provenir de la liaison d'une bibliothèque construite avec "Multithreaded Debug" (c.-à-d. CRT statique de débogage multithread) avec un programme qui est construit en utilisant "Multithreaded Debug". DLL "Vous devez modifier ce paramètre soit dans la bibliothèque, soit dans votre programme. Pour l'instant, je suggère de le changer dans votre programme.

Notez que, puisque les projets Visual Studio utilisent différents ensembles de paramètres de projet pour les builds de débogage et de version (et les builds 32/64 bits), vous devez vous assurer que les paramètres correspondent dans toutes ces configurations de projet.

Pour (un peu) plus d'informations, vous pouvez consulter ces pages (lien d'un commentaire ci-dessus) :

1. Avertissement concernant les outils de liaison LNK4098 sur MSDN
2. /MD, /ML, /MT, /LD (Utilisation de la bibliothèque d'exécution) sur MSDN
3. Erreurs de construction avec VC11 Beta - les librairies MTd mélangées aux exes MDd ne se lient pas sur Bugzilla@Mozilla

UPDATE (Ceci est en réponse à un commentaire qui demande la raison pour laquelle il faut prendre autant de précautions).

Si deux morceaux de code que nous lions ensemble sont eux-mêmes liés à la bibliothèque standard et l'utilisent, alors la bibliothèque standard doit être la même pour les deux, sauf si grand on prend soin de la façon dont nos deux morceaux de code interagissent et transmettent les données. En général, je dirais que pour presque toutes les situations, il suffit d'utiliser exactement la même version du runtime de la bibliothèque standard (en ce qui concerne le débogage/la libération, les threads, et évidemment la version de Visual C++, entre autres choses comme le débogage des itérateurs, etc.)

La partie la plus importante du problème est la suivante : avoir la même idée de la taille des objets de part et d'autre d'un appel de fonction .

Considérons par exemple que les deux morceaux de code ci-dessus sont appelés A y B . A est compilé contre une version de la bibliothèque standard, et B contre une autre. Du point de vue de A, un objet aléatoire qu'une fonction standard lui renvoie (par exemple, un bloc de mémoire, un itérateur ou une fonction FILE ou autre) a une taille et une disposition spécifiques (n'oubliez pas que la disposition de la structure est déterminée et fixée au moment de la compilation en C/C++). Pour plusieurs raisons, l'idée que se fait B de la taille et de la disposition des mêmes objets est différente (cela peut être dû à des informations de débogage supplémentaires, à l'évolution naturelle des structures de données au fil du temps, etc.)

Maintenant, si A appelle la bibliothèque standard et obtient un objet en retour, puis transmet cet objet à B, et que B touche cet objet d'une manière ou d'une autre, il y a de fortes chances que B abîme cet objet (par exemple, en écrivant le mauvais champ, ou en dépassant la fin de l'objet, etc.)

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

Tout cela devient plus étrange à certains égards lorsque l'on utilise des DLL (dynamic runtime library) au lieu de libs (static runtime library).

Cette situation peut s'appliquer à toute bibliothèque utilisée par deux morceaux de code qui travaillent ensemble, mais la bibliothèque standard est utilisée par la plupart (si ce n'est la quasi-totalité) des programmes, ce qui augmente les risques de conflit.

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

Answer 2

J'ai eu ce problème ainsi qu'un décalage dans ITERATOR_DEBUG_LEVEL. Comme un problème de dimanche soir après que tout semblait ok et bon pour aller, j'ai été mis hors tension pendant un certain temps. Travaillant dans l'IDE de VS2017 (Solution Explorer), j'avais récemment ajouté/copié une référence de fichier source à mon projet (ctrl-drag) à partir d'un autre projet. En regardant dans les propriétés->C/C++/Préprocesseur. au niveau du fichier source, et non du projet - J'ai remarqué que dans une configuration Release _DEBUG a été spécifié au lieu de NDEBUG pour ce fichier source. C'était le seul changement nécessaire pour se débarrasser du problème.

Answer 3

J'ai téléchargé et extrait Crypto++ en 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 j'ai 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 pouvez pas le savoir tant que vous ne rencontrez pas les erreurs que vous voyez. Pour plus de détails, voir Visual Studio sur le wiki Crypto++.

---

Une idée pour réparer cela ?

Pour résoudre vos problèmes, vous devez télécharger vs2010.zip si vous voulez une liaison statique C/C++ au moment de l'exécution ( /MT o /MTd ), ou vs2010-dynamic.zip si vous voulez une liaison dynamique C/C++ au moment de l'exécution ( /MT o /MTd ). Tous deux corrigent les défaillances latentes et silencieuses produites par VCUpgrade.

---

vs2010.zip , vs2010-dynamic.zip y vs2005-dynamic.zip sont construits à partir du dernières sources GitHub . Au moment où nous écrivons ces lignes (1er juin 2016), il s'agit effectivement d'une version antérieure à Crypto++ 5.6.4. Si vous utilisez les fichiers ZIP avec un Crypto++ de niveau inférieur, comme 5.6.2 ou 5.6.3, vous rencontrerez des problèmes mineurs.

Il y a deux problèmes mineurs dont je suis conscient. Le premier est un renommage de bench.cpp à 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)

La solution est soit (1) d'ouvrir cryptest.vcxproj dans le bloc-notes, trouver bench1.cpp puis le renommer en bench.cpp . Ou (2) renommer bench.cpp à bench1.cpp sur le système de fichiers. Veuillez ne pas supprimer ce fichier.

Le deuxième problème est un peu plus délicat car il s'agit d'une cible mouvante. Les versions de niveau inférieur, comme 5.6.2 ou 5.6.3, n'ont pas les dernières classes disponibles dans la base de données de l GitHub . Les fichiers de classe manquants comprennent 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.

La solution 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 dernières sources, mais cela pourrait entraîner des complications. Par exemple, beaucoup de sources dépendent subtilement de la dernière version de config.h , cpu.h y cpu.cpp . La "subtilité" est que vous ne vous rendrez pas compte que vous obtenez une classe sous-performante.

Un exemple de classe peu performante est BLAKE2. config.h ajoute la détection des ARM-32 et ARM-64 à la compilation. cpu.h y cpu.cpp ajoute la détection des instructions ARM à l'exécution, qui dépend de la détection à la compilation. Si vous ajoutez BLAKE2 sans les autres fichiers, alors aucune détection ne se produit et vous obtenez une implémentation C/C++ directe. Vous ne vous rendrez probablement pas compte que vous manquez l'opportunité NEON, qui tourne autour de 9 à 12 cycles par octet contre 40 cycles par octet environ pour le C/C++ classique.

Answer 4

Le problème peut être résolu en ajoutant CRT de msvcrtd.lib dans la bibliothèque du linker. Car cryptlib.lib utilise la version CRT de debug.