it-swarm.com.de

Nichtübereinstimmung für 'RuntimeLibrary' festgestellt

Ich habe Crypto ++ in C:\cryptopp heruntergeladen und extrahiert. Ich habe Visual Studio Express 2012 verwendet, um alle darin enthaltenen Projekte zu erstellen (wie in der Readme-Datei angegeben), und alles wurde erfolgreich erstellt. Dann habe ich ein Testprojekt in einem anderen Ordner erstellt und cryptolib als Abhängigkeit hinzugefügt. Danach habe ich den Include-Pfad hinzugefügt, damit ich alle Header problemlos einbinden kann. Beim Kompilieren ist mir ein Fehler bei nicht aufgelösten Symbolen aufgefallen.

Um dem abzuhelfen, habe ich C:\cryptopp\Win32\Output\Debug\cryptlib.lib, um zusätzliche Abhängigkeiten zu verknüpfen. Jetzt bekomme ich diesen Fehler:

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

Ich bekomme auch:

Error   12  error LNK2005: "public: __thiscall std::_Container_base12::_Container_base12(void)" ([email protected]@@[email protected]) 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)" ([email protected]@@[email protected]) 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)" ([email protected][email protected]@@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)" ([email protected]@[email protected]@[email protected]@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

Der Code, den ich zu kompilieren versuchte, war einfach (ich habe diesen Code von einer anderen Site erhalten):

#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;
}

Irgendwelche Ideen, wie man das behebt? Ich brauche jetzt wirklich nur SHA-256, sonst nichts. Ich verwende Windows 7 64-Bit und habe heute VS C++ heruntergeladen, daher sollte es die neueste Version sein.

102
Momonga

(Dies wird bereits in Kommentaren beantwortet, aber da es an einer tatsächlichen Antwort mangelt, schreibe ich dies.)

Dieses Problem tritt in neueren Versionen von Visual C++ auf (die älteren Versionen haben das Programm normalerweise nur unbemerkt verlinkt und es stürzte zur Laufzeit ab und brannte.) Dies bedeutet, dass einige der Bibliotheken, die Sie mit Ihrem Programm verknüpfen (oder sogar einige der Quellen) Dateien in Ihrem Programm selbst) verwenden verschiedene Versionen des CRT (die C RunTime-Bibliothek.)

Um diesen Fehler zu beheben, müssen Sie in Ihr Project Properties (und/oder die der Bibliotheken, die Sie verwenden), dann in C/C++, dann Code Generation, und überprüfen Sie den Wert von Runtime Library; Dies sollte für alle Dateien und Bibliotheken, die Sie miteinander verknüpfen, genau gleich sein. (Die Regeln für das Verknüpfen mit DLLs sind etwas lockerer, aber ich werde hier nicht auf das "Warum" und weitere Details eingehen.)

Es gibt derzeit vier Optionen für diese Einstellung:

  1. Multithread-Debug
  2. Multithread-Debug-DLL
  3. Multithread-Version
  4. Multithread-Versions-DLL

Ihr spezielles Problem scheint darauf zurückzuführen zu sein, dass Sie eine Bibliothek, die mit "Multithreaded Debug" (dh statischem Multithreaded-Debug-CRT) erstellt wurde, mit einem Programm verknüpfen, das mit "Multithreaded Debug [~ # ~] dll [ ~ # ~] "Einstellung (dh dynamisches Multithread-Debug-CRT). Sie sollten diese Einstellung entweder in der Bibliothek oder in Ihrem Programm ändern. Im Moment schlage ich vor, dies in Ihrem Programm zu ändern.

Beachten Sie, dass Sie sicherstellen sollten, dass die Einstellungen in all diesen Projektkonfigurationen übereinstimmen, da Visual Studio-Projekte unterschiedliche Projekteinstellungen für Debug- und Release-Builds (und 32/64-Bit-Builds) verwenden.

Für (einige) weitere Informationen können Sie diese sehen (von einem Kommentar oben verlinkt):

  1. Linker Tools Warning LNK4098 auf MSDN
  2. / MD,/ML,/MT,/LD (Laufzeitbibliothek verwenden) auf MSDN
  3. Build-Fehler mit VC11 Beta - Mischen von MTd-Bibliotheken mit MDd-Exes schlägt fehl auf Bugzilla @ Mozilla

[~ # ~] update [~ # ~] : (Dies ist eine Antwort auf einen Kommentar, in dem der Grund angeführt wird, warum so viel Sorgfalt geboten ist .)

Wenn zwei Codeteile, die wir miteinander verknüpfen, selbst mit der Standardbibliothek verknüpft sind und diese verwenden, muss die Standardbibliothek für beide identisch sein, sofern nicht große Sorgfalt angewendet wird darüber, wie unsere beiden Codeteile interagieren und Daten weitergeben. Im Allgemeinen würde ich sagen, dass für fast alle Situationen genau dieselbe Version der Standardbibliothekslaufzeit verwendet wird (in Bezug auf Debug/Release, Threads und natürlich die Version von Visual C++, unter anderem Iterator-Debugging usw.).

Der wichtigste Teil des Problems ist folgender: Die gleiche Vorstellung von der Größe von Objekten auf beiden Seiten eines Funktionsaufrufs .

Stellen Sie sich zum Beispiel vor, dass die beiden obigen Codeteile A und B heißen. A wird für eine Version der Standardbibliothek kompiliert und B für eine andere. In der Ansicht von A hat ein zufälliges Objekt, zu dem eine Standardfunktion zurückkehrt (z. B. ein Speicherblock oder ein Iterator oder ein FILE -Objekt oder was auch immer), eine bestimmte Größe und ein bestimmtes Layout (denken Sie daran, dass das Strukturlayout festgelegt und festgelegt ist Zur Kompilierungszeit in C/C++.) Aus verschiedenen Gründen unterscheidet sich B hinsichtlich der Größe/des Layouts derselben Objekte (dies kann an zusätzlichen Debuginformationen, der natürlichen Entwicklung von Datenstrukturen im Laufe der Zeit usw. liegen).

Wenn nun A die Standardbibliothek aufruft und ein Objekt zurückerhält, dieses Objekt an B übergibt und B dieses Objekt auf irgendeine Weise berührt, besteht die Möglichkeit, dass B dieses Objekt durcheinander bringt (z. B. das falsche Feld schreiben oder das Ende überschreiten) davon usw.)

Das Obige ist nicht die einzige Art von Problemen, die auftreten können. Interne globale oder statische Objekte in der Standardbibliothek können ebenfalls Probleme verursachen. Und es gibt auch weitere undurchsichtige Problemklassen.

All dies wird in einigen Aspekten seltsamer, wenn DLLs (Dynamic Runtime Library) anstelle von libs (Static Runtime Library) verwendet werden.

Diese Situation kann für jede Bibliothek gelten, die von zwei Codeteilen verwendet wird, die zusammenarbeiten. Die Standardbibliothek wird jedoch von den meisten (wenn nicht fast allen) Programmen verwendet, und dies erhöht die Wahrscheinlichkeit von Konflikten.

Was ich beschrieben habe, ist offensichtlich eine verwässerte und vereinfachte Version des tatsächlichen Chaos, das Sie erwartet, wenn Sie Bibliotheksversionen mischen. Ich hoffe, dass es Ihnen eine Idee gibt, warum Sie es nicht tun sollten!

213
yzt

Ich habe Crypto ++ in C:\cryptopp heruntergeladen und extrahiert. Ich habe Visual Studio Express 2012 verwendet, um alle darin enthaltenen Projekte zu erstellen (wie in der Readme-Datei angegeben), und alles wurde erfolgreich erstellt. Dann habe ich ein Testprojekt in einem anderen Ordner erstellt und cryptolib als Abhängigkeit hinzugefügt.

Die Konvertierung war wahrscheinlich nicht erfolgreich. Das einzige, was erfolgreich war, war der Betrieb von VCUpgrade. Die eigentliche Konvertierung selbst ist fehlgeschlagen, Sie wissen es jedoch erst, wenn die angezeigten Fehler auftreten. Für einige Details siehe Visual Studio im Crypto ++ Wiki.


Irgendwelche Ideen, wie man das behebt?

Um Ihre Probleme zu beheben, sollten Sie vs2010.Zip herunterladen, wenn Sie eine statische C/C++ - Laufzeitverknüpfung (/MT Oder /MTd) Wünschen, oder vs2010-dynamic.Zip Wenn Sie eine dynamische C/C++ - Laufzeitverknüpfung wünschen (/MT Oder /MTd). Beide beheben die von VCUpgrade verursachten latenten, stillen Fehler.


vs2010.Zip , vs2010-dynamic.Zip und vs2005-dynamic.Zip werden aus dem neuesten) erstellt GitHub-Quellen . Zum jetzigen Zeitpunkt (1. Juni 2016) ist dies effektiv vor Crypto ++ 5.6.4. Wenn Sie die Zip-Dateien mit einem älteren Crypto ++ wie 5.6.2 oder 5.6.3 verwenden, treten kleinere Probleme auf.

Mir sind zwei kleinere Probleme bekannt. Erstens ist eine Umbenennung von bench.cpp In bench1.cpp . Sein Fehler ist entweder:

  • 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)" ([email protected]@[email protected])

Das Update besteht darin, entweder (1) cryptest.vcxproj Im Editor zu öffnen, bench1.cpp Zu suchen und es dann in bench.cpp Umzubenennen. Oder (2) benennen Sie bench.cpp Im Dateisystem in bench1.cpp Um. Bitte löschen Sie diese Datei nicht.

Das zweite Problem ist etwas kniffliger, weil es sich um ein sich bewegendes Ziel handelt. In älteren Versionen wie 5.6.2 oder 5.6.3 fehlen die neuesten Klassen, die in GitHub verfügbar sind. Zu den fehlenden Klassendateien gehören HKDF (5.6.3), RDRAND (5.6.3), RDSEED (5.6.3), ChaCha (5.6.4), BLAKE2 (5.6.4), Poly1305 (5.6.4) usw.

Das Update besteht darin, die fehlenden Quelldateien aus den Visual Studio-Projektdateien zu entfernen, da sie für die älteren Versionen nicht vorhanden sind.

Eine andere Möglichkeit besteht darin, die fehlenden Klassendateien aus den neuesten Quellen hinzuzufügen. Es kann jedoch zu Komplikationen kommen. Beispielsweise hängen viele der Quellen subtil von den neuesten config.h, cpu.h Und cpu.cpp Ab. Die "Subtilität" ist, dass Sie nicht bemerken, dass Sie eine Klasse mit schlechter Leistung bekommen.

Ein Beispiel für eine unterdurchschnittliche Leistung ist BLAKE2. config.h Fügt die Kompilierzeit für die Erkennung von ARM-32 und ARM-64 hinzu. cpu.h Und cpu.cpp Fügen die Befehlserkennung zur Laufzeit ARM hinzu, die von der Erkennung der Kompilierungszeit abhängt. Wenn Sie BLAKE2 ohne die anderen Dateien hinzufügen, tritt keine Erkennung auf und Sie erhalten eine direkte C/C++ - Implementierung. Sie werden wahrscheinlich nicht bemerken, dass Sie die NEON-Gelegenheit verpassen, die bei Vanilla C/C++ zwischen 9 und 12 Zyklen pro Byte und bei Vanilla C/C++ zwischen 40 Zyklen pro Byte liegt.

3
jww

Ich hatte dieses Problem zusammen mit einem Konflikt in ITERATOR_DEBUG_LEVEL. Da ein Sonntag-Abend-Problem immerhin in Ordnung und gut zu gehen schien, wurde ich für einige Zeit ausgesetzt. Arbeiten in de VS2017 IDE (Solution Explorer) Ich habe kürzlich einen Quelldateiverweis zu meinem Projekt hinzugefügt/aus einem anderen Projekt kopiert (Strg + Ziehen). auf Quelldateiebene, nicht auf Projektebene - Ich habe festgestellt, dass in einer Release-Konfiguration _DEBUG anstelle von NDEBUG für diese Quelldatei angegeben wurde. Dies war die einzige Änderung, die erforderlich war, um das Problem zu beheben.

3
Jan

Das Problem kann durch Hinzufügen der CRT-Datei msvcrtd.lib in der Linker-Bibliothek behoben werden. Weil cryptlib.lib die CRT-Version des Debugs verwendet hat.

0
abhijithkp