Descargué y extraje Crypto ++ en C: \ cryptopp. Usé Visual Studio Express 2012 para construir todos los proyectos internos (como se indica en el archivo Léame), y todo se construyó correctamente. Luego hice un proyecto de prueba en otra carpeta y agregué cryptolib como dependencia. Después de eso, agregué la ruta de inclusión para poder incluir fácilmente todos los encabezados. Cuando intenté compilar, recibí un error sobre los símbolos sin resolver.
Para remediar eso, agregué C:\cryptopp\Win32\Output\Debug\cryptlib.lib
para vincular dependencias adicionales. Ahora me sale este error:
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
También obtengo:
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
El código que intenté compilar fue simple (lo obtuve de otro sitio):
#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;
}
Alguna idea de cómo solucionar este problema? Realmente solo necesito SHA-256 en este momento, nada más. Estoy usando Windows 7 de 64 bits y descargué VS C ++ hoy, por lo que debería ser la versión más nueva.
VCUpgrade
. Está viendo síntomas de la falla de VCUpgrade que se le informó como un éxito .Respuestas:
(Esto ya está respondido en los comentarios, pero como carece de una respuesta real , estoy escribiendo esto).
Este problema surge en las versiones más recientes de Visual C ++ (las versiones anteriores generalmente solo vinculaban silenciosamente el programa y se bloqueaba y quemaba en tiempo de ejecución). Significa que algunas de las bibliotecas que está vinculando con su programa (o incluso algunas de las fuentes archivos dentro de su programa) están usando diferentes versiones de CRT (la biblioteca C RunTime).
Para corregir este error, debe ir a su
Project Properties
(y / o las de las bibliotecas que está utilizando), luego aC/C++
, luegoCode Generation
, y verificar el valor deRuntime Library
; esto debería ser exactamente igual para todos los archivos y bibliotecas que está vinculando. (Las reglas son un poco más relajadas para la vinculación con archivos DLL, pero no voy a entrar en el "por qué" ni en más detalles aquí).Actualmente hay cuatro opciones para esta configuración:
Su problema particular parece provenir de que usted vincule una biblioteca construida con "Depuración multiproceso" (es decir, CRT de depuración multiproceso estático) con un programa que se está construyendo usando la " DLL de depuración multiproceso configuración " " (es decir, CRT de depuración multiproceso dinámico). esta configuración en la biblioteca o en su programa. Por ahora, sugiero cambiar esto en su programa.
Tenga en cuenta que, dado que los proyectos de Visual Studio usan diferentes conjuntos de configuraciones de proyecto para depurar y publicar compilaciones (y compilaciones de 32/64 bits), debe asegurarse de que la configuración coincida en todas estas configuraciones de proyecto.
Para (algo) más información, puede ver estos (enlazados desde un comentario anterior):
ACTUALIZACIÓN : (Esto es en respuesta a un comentario que pregunta la razón por la que se debe tener tanto cuidado).
Si dos fragmentos de código que estamos vinculando juntos se vinculan y utilizan la biblioteca estándar, entonces la biblioteca estándar debe ser la misma para ambos, a menos que sea excelente. cuidado con la forma en que nuestros dos fragmentos de código interactúan y pasan los datos. En general, diría que para casi todas las situaciones simplemente use exactamente la misma versión del tiempo de ejecución de la biblioteca estándar (con respecto a la depuración / liberación, subprocesos y, obviamente, la versión de Visual C ++, entre otras cosas como la depuración del iterador, etc.)
La parte más importante del problema es la siguiente: tener la misma idea sobre el tamaño de los objetos a cada lado de una llamada de función .
Considere, por ejemplo, que los dos fragmentos de código anteriores se denominan
A
yB
. A se compila con una versión de la biblioteca estándar y B con otra. En la vista de A, algún objeto aleatorio al que una función estándar le devuelve (por ejemplo, un bloque de memoria o un iterador o unFILE
objeto o lo que sea) tiene un tamaño y diseño específicos (recuerde que el diseño de la estructura se determina y se fija en el momento de la compilación en C / C ++.) Por varias razones, la idea de B sobre el tamaño / diseño de los mismos objetos es diferente (puede deberse a información adicional de depuración, evolución natural de las estructuras de datos a lo largo del tiempo, etc.)Ahora, si A llama a la biblioteca estándar y recupera un objeto, luego pasa ese objeto a B, y B toca ese objeto de alguna manera, es probable que B estropee ese objeto (por ejemplo, escriba el campo incorrecto o más allá del final de eso, etc.)
Lo anterior no es el único tipo de problemas que pueden ocurrir. Los objetos internos globales o estáticos de la biblioteca estándar también pueden causar problemas. Y también hay clases de problemas más oscuras.
Todo esto se vuelve más extraño en algunos aspectos cuando se usan DLL (biblioteca dinámica en tiempo de ejecución) en lugar de libs (biblioteca estática en tiempo de ejecución).
Esta situación puede aplicarse a cualquier biblioteca utilizada por dos piezas de código que funcionan juntas, pero la biblioteca estándar es utilizada por la mayoría (si no casi todos) los programas, y eso aumenta las posibilidades de conflicto.
Lo que he descrito es, obviamente, una versión diluida y simplificada del lío real que le espera si mezcla las versiones de la biblioteca. ¡Espero que te dé una idea de por qué no deberías hacerlo!
fuente
Probablemente la conversión no se haya realizado correctamente. Lo único que tuvo éxito fue la ejecución de VCUpgrade. La conversión real falló, pero no lo sabrá hasta que experimente los errores que está viendo. Para obtener algunos detalles, consulte Visual Studio en la wiki de Crypto ++.
Para resolver sus problemas, debe descargar
vs2010.zip
si desea un enlace de tiempo de ejecución de C / C ++ estático (/MT
o/MTd
), ovs2010-dynamic.zip
si desea un enlace de tiempo de ejecución de C / C ++ dinámico (/MT
o/MTd
). Ambos arreglan los fallos silenciosos y latentes producidos por VCUpgrade.vs2010.zip
,vs2010-dynamic.zip
Yvs2005-dynamic.zip
se construyen a partir de las últimas fuentes de GitHub . En el momento de escribir este artículo (1 de junio de 2016), eso es efectivamente anterior a Crypto ++ 5.6.4. Si está utilizando archivos ZIP con un nivel inferior de Crypto ++, como 5.6.2 o 5.6.3, se encontrará con problemas menores.Hay dos problemas menores que conozco. Primero es un cambio de nombre de
bench.cpp
abench1.cpp
. Su error es: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 solución es (1) abrir
cryptest.vcxproj
en el bloc de notas, buscarbench1.cpp
y luego cambiarle el nombre abench.cpp
. O (2) cambiar el nombrebench.cpp
abench1.cpp
en el sistema de archivos. No elimine este archivo.El segundo problema es un poco más complicado porque es un objetivo en movimiento. A las versiones de nivel inferior, como 5.6.2 o 5.6.3, les faltan las últimas clases disponibles en GitHub . Los archivos de clase que faltan incluyen 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 solución es eliminar los archivos fuente que faltan de los archivos del proyecto de Visual Studio, ya que no existen para las versiones de nivel inferior.
Otra opción es agregar los archivos de clases que faltan de las fuentes más recientes, pero podría haber complicaciones. Por ejemplo, muchas de las fuentes sutilmente dependen de la última
config.h
,cpu.h
ycpu.cpp
. La "sutileza" es que no se dará cuenta de que está obteniendo una clase de bajo rendimiento.Un ejemplo de clase de bajo rendimiento es BLAKE2.
config.h
agrega tiempo de compilación de detección ARM-32 y ARM-64.cpu.h
ycpu.cpp
agrega detección de instrucciones ARM en tiempo de ejecución, que depende de la detección del tiempo de compilación. Si agrega BLAKE2 sin los otros archivos, entonces no se produce ninguna detección y obtiene una implementación directa de C / C ++. Probablemente no se dé cuenta de que está perdiendo la oportunidad NEON, que se ejecuta alrededor de 9 a 12 ciclos por byte frente a 40 ciclos por byte más o menos para Vanilla C / C ++.fuente
Tuve este problema junto con una falta de coincidencia en ITERATOR_DEBUG_LEVEL. Como un problema de los domingos por la noche, después de todo parecía estar bien y bueno, me sentí molesto por un tiempo. Trabajando en el IDE de VS2017 (Explorador de soluciones), recientemente había agregado / copiado una referencia de archivo de origen a mi proyecto (ctrl-drag) de otro proyecto. Mirando las propiedades-> C / C ++ / Preprocesador - en el nivel del archivo fuente, no en el nivel del proyecto - noté que en una configuración de lanzamiento se especificó _DEBUG en lugar de NDEBUG para este archivo fuente. Que fue todo el cambio necesario para solucionar el problema.
fuente
El problema se puede resolver agregando CRT de msvcrtd.lib en la biblioteca del vinculador. Porque cryptlib.lib usó la versión CRT de debug.
fuente