Delay-Load-Krypto ++ cryptop.dll

Question

Die Crypto ++ - Bibliothek unterstützt späte Bindung durch Kompilieren gegen cryptlib.lib und cryptopp.lib. Dies erfordert die Verwendung der cryptopp.dll. Wenn Sie versuchen, diese DLL um /DELAYLOAD:cryptopp.dll zu verzögern, verursacht dies einen Verbindungsfehler, der wegen erforderlicher Importe nicht verzögert geladen werden konnte.

Als Beispiel sehen Sie den folgenden Code:

#include <Crypto++/dll.h> 
#include <crypto++/base64.h> 

bool HexDecode(const std::string& strHex, std::string& strData) 
{ 
    try 
    { 
     CryptoPP::StringSource(strHex, true, 
      new CryptoPP::Base64Decoder(
       new CryptoPP::StringSink(strData))); 
    } 

    catch(...) 
    { 
     return false; 
    } 

    return true; 
} 

Dies führt zu den folgenden Link Fehler:

LINK : fatal error LNK1194: Delay loading "cryptopp.dll" not possible because of import of data symbol ""__declspec(dllimport) bool (__cdecl* CryptoPP::g_pAssignIntToInteger)(class type_info const &,void *,void const *)" (__imp_?g_pAssignIntToInteger@CryptoPP@@3P6A_NABVtype_info@@PAXPBX@ZA)". Link without /DELAYLOAD:cryptopp.dll 

Hat jemand schon geschafft Last zu verzögern cryptopp.dll erfolgreich?

Answer 1

The Crypto++ library supports late binding by compiling against cryptlib.lib and cryptopp.lib...

Die DLL ist eine FIPS-DLL. Der eigentliche Zweck der Aufteilung der Funktionalität in zwei separate Bibliotheken besteht darin, die logische Modulgrenze bereitzustellen, die von FIPS 140-2 benötigt wird. Die FIPS-Modulgrenze ist cryptopp.dll.

Die FIPS-DLL enthält nur die FIPS-Algorithmen wie AES und RSA. Ich empfehle Ihnen, die FIPS-DLL um jeden Preis zu vermeiden. Es ist ein Schmerz, mit dem man arbeiten kann. Siehe auch FIPS DLL im Crypto ++ Wiki.

Wenn Sie eine DLL wünschen, dann schreiben Sie Ihre eigene Wrapper-DLL mit Ihrer eigenen API und verlinken Sie dann mit der statischen Crypto ++ - Bibliothek.

In der Wrapper-DLL Fall (und da Sie scheinen erfahrene), empfehle ich Ihnen, cryptest.nmake als Ausgangspunkt zu verwenden. Wenn Sie mit Makefiles vertraut sind (ich denke, Sie sind), dann werden Sie es viel einfacher finden, mit zu arbeiten als die Visual Studio project files.

---

LINK : fatal error LNK1194: Delay loading "cryptopp.dll" not possible because of import of data symbol ""__declspec(dllimport) bool (__cdecl* CryptoPP::g_pAssignIntToInteger)(class type_info const &,void *,void const *)" (__imp_?g_pAssignIntToInteger@CryptoPP@@3P6A_NABVtype_info@@PAXPBX@ZA)". Link without /DELAYLOAD:cryptopp.dll

Dies ist eine interessante Frage, weil Sie zwei Bibliotheken haben, und es ist nicht mir klar, welche Bibliothek das Symbol in ist. Die erste Bibliothek ist die FIPS-DLL (cryptopp.dll), und es enthält AES, RSA, etc. Die zweite Bibliothek ist die Static Lib (cryptlib.lib), und sie enthält HexEncoder, FileSource und die anderen unterstützenden Sachen.

Ich glaube, g_pAssignIntToInteger sollte in der Static Lib (cryptlib.lib) sein, weil es Teil von AlgorithmParamters war. Siehe beispielsweise Commit 5efb019d8bdc593b. Aufgrund des obigen Fehlers scheint es jedoch aufgrund des Symbolnamens __imp_?g_pAssignIntToInteger ... in der FIPS-DLL zu verbleiben.

Jetzt ist die zusätzliche Falte, g_pAssignIntToInteger ist ein Funktionszeiger, und Compiler werden sie nicht optimieren. Der Linker verwirft also nie Integer verwandte Symbole, was der Punkt der Entkopplung ist.

Bei Commit 0e55f5ac7d98f3c8 entfernten wir g_pAssignIntToInteger und fügten eine Definition CRYPTOPP_NO_ASSIGN_TO_INTEGER hinzu, um die Aufgabe zu erfüllen. Die Definition stellt sicher, dass das Symbol und unerwünschter Code wie Integer Code verworfen werden kann.