Error de coincidencia detectado para 'RuntimeLibrary'

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.libpara 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.

(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 a C/C++, luego Code Generation, y verificar el valor de Runtime 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:

1. Depuración multiproceso
2. DLL de depuración multiproceso
3. Lanzamiento multiproceso
4. DLL de versión multiproceso

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):

1. Advertencia de las herramientas del vinculador LNK4098 en MSDN
2. / MD, / ML, / MT, / LD (Usar biblioteca en tiempo de ejecución) en MSDN
3. Errores de compilación con VC11 Beta: la combinación de bibliotecas de MTd con ex de MDd no se puede vincular en Bugzilla @ Mozilla

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 Ay B. 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 un FILEobjeto 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!

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.

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 ++.

Alguna idea de cómo solucionar este problema?

Para resolver sus problemas, debe descargar vs2010.zipsi desea un enlace de tiempo de ejecución de C / C ++ estático ( /MTo /MTd), o vs2010-dynamic.zipsi desea un enlace de tiempo de ejecución de C / C ++ dinámico ( /MTo /MTd). Ambos arreglan los fallos silenciosos y latentes producidos por VCUpgrade.

vs2010.zip, vs2010-dynamic.zipY vs2005-dynamic.zipse 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.cppabench1.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.vcxprojen el bloc de notas, buscar bench1.cppy luego cambiarle el nombre a bench.cpp. O (2) cambiar el nombre bench.cppa bench1.cppen 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.hy cpu.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.hagrega tiempo de compilación de detección ARM-32 y ARM-64. cpu.hy cpu.cppagrega 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 ++.

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.

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.