问题描述

我在 C:cryptopp 中下载并解压了 Crypto++.我使用 Visual Studio Express 2012 来构建里面的所有项目(按照自述文件中的说明)，一切都构建成功.然后我在其他文件夹中创建了一个测试项目，并添加了 cryptolib 作为依赖项.之后，我添加了包含路径，以便我可以轻松包含所有标题.当我尝试编译时，我收到关于未解析符号的错误.

I downloaded and extracted Crypto++ in C:cryptopp. I used Visual Studio Express 2012 to build all the projects inside (as instructed in readme), and everything was built successfully. Then I made a test project in some other folder and added cryptolib as a dependency. After that, I added the include path so I can easily include all the headers. When I tried to compile, I got an error about unresolved symbols.

为了解决这个问题，我添加了 C:cryptoppWin32OutputDebugcryptlib.lib 来链接其他依赖项.现在我收到此错误:

To remedy that, I added C:cryptoppWin32OutputDebugcryptlib.lib to link additional dependencies. Now I get this error:

Error   1   error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj    C:DataWorkC++ VSCryptoTestCryptoTestcryptlib.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:DataWorkC++ VSCryptoTestCryptoTestcryptlib.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:DataWorkC++ VSCryptoTestCryptoTestcryptlib.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:DataWorkC++ VSCryptoTestCryptoTestcryptlib.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:DataWorkC++ VSCryptoTestCryptoTestcryptlib.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:DataWorkC++ VSCryptoTestCryptoTestcryptlib.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:DataWorkC++ VSCryptoTestCryptoTestcryptlib.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:DataWorkC++ VSCryptoTestCryptoTestcryptlib.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:DataWorkC++ VSCryptoTestCryptoTestcryptlib.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:DataWorkC++ VSCryptoTestCryptoTestcryptlib.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:DataWorkC++ VSCryptoTestCryptoTestcryptlib.lib(mqueue.obj)  CryptoTest

我也得到:

Error   12  error LNK2005: "public: __thiscall std::_Container_base12::_Container_base12(void)" (??0_Container_base12@QAE@XZ) already defined in cryptlib.lib(cryptlib.obj)    C:DataWorkC++ VSCryptoTestCryptoTestmsvcprtd.lib(MSVCP110D.dll)   CryptoTest
Error   13  error LNK2005: "public: __thiscall std::_Container_base12::~_Container_base12(void)" (??1_Container_base12@QAE@XZ) already defined in cryptlib.lib(cryptlib.obj)   C:DataWorkC++ VSCryptoTestCryptoTestmsvcprtd.lib(MSVCP110D.dll)   CryptoTest
Error   14  error LNK2005: "public: void __thiscall std::_Container_base12::_Orphan_all(void)" (?_Orphan_all@_Container_base12@QAEXXZ) already defined in cryptlib.lib(cryptlib.obj)   C:DataWorkC++ VSCryptoTestCryptoTestmsvcprtd.lib(MSVCP110D.dll)   CryptoTest
Error   15  error LNK2005: "public: __thiscall std::locale::id::id(unsigned int)" (??0idstd@@QAE@I@Z) already defined in cryptlib.lib(iterhash.obj) C:DataWorkC++ VSCryptoTestCryptoTestmsvcprtd.lib(MSVCP110D.dll)   CryptoTest
Warning 16  warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of other libs; use /NODEFAULTLIB:library   C:DataWorkC++ VSCryptoTestCryptoTestLINK  CryptoTest
Error   17  error LNK1169: one or more multiply defined symbols found   C:DataWorkC++ VSCryptoTestDebugCryptoTest.exe 1   1   CryptoTest

我试图编译的代码很简单(我从另一个站点得到了这个):

The code I tried to compile was simple (I got this from another 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;
}

任何想法如何解决这个问题?我现在真的只需要 SHA-256，没有别的.我用的是Windows 7 64位，今天下载了VS C++，应该是最新版本.

Any ideas how to fix this? I really only need SHA-256 right now, nothing else. I am using Windows 7 64 bit, and I downloaded VS C++ today, so it should be the newest version.

推荐答案

(这已经在评论中回答了，但由于它缺乏实际的答案，我正在写这个.)

(This is already answered in comments, but since it lacks an actual answer, I'm writing this.)

这个问题出现在较新版本的 Visual C++ 中(旧版本通常只是默默地链接程序，它会在运行时崩溃和烧毁.)这意味着您正在与程序链接的某些库(甚至某些程序本身中的源文件)使用不同版本的 CRT(C 运行时库).

This problem arises in newer versions of Visual C++ (the older versions usually just silently linked the program and it would crash and burn at run time.) It means that some of the libraries you are linking with your program (or even some of the source files inside your program itself) are using different versions of the CRT (the C RunTime library.)

要纠正此错误，您需要进入项目属性(和/或您正在使用的库的属性)，然后进入C/C++，然后Code Generation，并检查Runtime Library的值；对于所有您链接在一起的文件和库，这应该完全相同.(与 DLL 链接的规则稍微宽松一些，但我不打算在这里讨论为什么"和更多细节.)

To correct this error, you need to go into your Project Properties (and/or those of the libraries you are using,) then into C/C++, then Code Generation, and check the value of Runtime Library; this should be exactly the same for all the files and libraries you are linking together. (The rules are a little more relaxed for linking with DLLs, but I'm not going to go into the "why" and into more details here.)

此设置目前有四个选项:

There are currently four options for this setting:

1. 多线程调试
2. 多线程调试DLL
3. 多线程发布
4. 多线程发布 DLL

您的特定问题似乎源于您将使用多线程调试"(即静态多线程调试 CRT)构建的库与使用多线程调试DLL"设置构建的程序链接起来(即动态多线程调试 CRT.)您应该在库或程序中更改此设置.目前，我建议在您的程序中更改此设置.

Your particular problem seems to stem from you linking a library built with "Multithreaded Debug" (i.e. static multithreaded debug CRT) against a program that is being built using the "Multithreaded Debug DLL" setting (i.e. dynamic multithreaded debug CRT.) You should change this setting either in the library, or in your program. For now, I suggest changing this in your program.

请注意，由于 Visual Studio 项目对调试和发布版本(以及 32/64 位版本)使用不同的项目设置集，因此您应该确保所有这些项目配置中的设置都匹配.

Note that since Visual Studio projects use different sets of project settings for debug and release builds (and 32/64-bit builds) you should make sure the settings match in all of these project configurations.

有关(一些)更多信息，您可以查看这些(从上面的评论链接):

For (some) more information, you can see these (linked from a comment above):

1. 链接器工具警告 LNK4098在 MSDN 上
2. /MD、/ML、/MT,/LD(使用运行时库) 在 MSDN 上
3. 使用 VC11 Beta 构建错误 - 将 MTd 库与 MDd exe 混合无法链接 关于 Bugzilla@Mozilla

1. Linker Tools Warning LNK4098 on MSDN
2. /MD, /ML, /MT, /LD (Use Run-Time Library) on MSDN
3. Build errors with VC11 Beta - mixing MTd libs with MDd exes fail to link on Bugzilla@Mozilla

更新:(这是对一条评论的回应，该评论要求必须如此小心.)

UPDATE: (This is in response to a comment that asks for the reason that this much care must be taken.)

如果我们链接在一起的两段代码本身链接并使用标准库，那么标准库对它们来说必须是相同的，除非非常注意如何我们的两个代码片段交互并传递数据.一般来说，我会说在几乎所有情况下，只需使用标准库运行时的完全相同版本(关于调试/发布、线程，显然还有 Visual C++ 的版本，以及迭代器调试等)

If two pieces of code that we are linking together are themselves linking against and using the standard library, then the standard library must be the same for both of them, unless great care is taken about how our two code pieces interact and pass around data. Generally, I would say that for almost all situations just use the exact same version of the standard library runtime (regarding debug/release, threads, and obviously the version of Visual C++, among other things like iterator debugging, etc.)

这个问题最重要的部分是:对函数调用两边的对象大小有相同的想法.

The most important part of the problem is this: having the same idea about the size of objects on either side of a function call.

以上面两段代码为例，分别称为A和B.A 针对标准库的一个版本编译，而 B 针对另一个版本进行编译.在 A 看来，标准函数返回给它的一些随机对象(例如一块内存或一个迭代器或一个 FILE 对象或其他)具有一些特定的大小和布局(记住结构布局是确定的并在 C/C++ 编译时修复.)出于多种原因中的任何一个，B 对相同对象的大小/布局的想法是不同的(这可能是因为额外的调试信息、数据结构随时间的自然演变等.)

Consider for example that the above two pieces of code are called A and B. A is compiled against one version of the standard library, and B against another. In A's view, some random object that a standard function returns to it (e.g. a block of memory or an iterator or a FILE object or whatever) has some specific size and layout (remember that structure layout is determined and fixed at compile time in C/C++.) For any of several reasons, B's idea of the size/layout of the same objects is different (it can be because of additional debug information, natural evolution of data structures over time, etc.)

现在，如果 A 调用标准库并取回一个对象，然后将该对象传递给 B，并且 B 以任何方式接触该对象，则 B 很可能会弄乱该对象(例如，写入错误的字段，或超过它的结尾等)

Now, if A calls the standard library and gets an object back, then passes that object to B, and B touches that object in any way, chances are that B will mess that object up (e.g. write the wrong field, or past the end of it, etc.)

上述问题并不是唯一可能发生的问题.标准库中的内部全局或静态对象也可能导致问题.而且还有更模糊的问题类别.

The above isn't the only kind of problems that can happen. Internal global or static objects in the standard library can cause problems too. And there are more obscure classes of problems as well.

当使用 DLL(动态运行时库)而不是 libs(静态运行时库)时，所有这些在某些方面都会变得更奇怪.

All this gets weirder in some aspects when using DLLs (dynamic runtime library) instead of libs (static runtime library.)

这种情况适用于协同工作的两段代码使用的任何库，但标准库被大多数(如果不是几乎所有)程序使用，这增加了冲突的可能性.

This situation can apply to any library used by two pieces of code that work together, but the standard library gets used by most (if not almost all) programs, and that increases the chances of clash.

我所描述的显然是一个经过淡化和简化的版本，如果您混合库版本，那么等待您的实际混乱情况.我希望它能让您了解为什么不应该这样做！

What I've described is obviously a watered down and simplified version of the actual mess that awaits you if you mix library versions. I hope that it gives you an idea of why you shouldn't do it!

这篇关于检测到“RuntimeLibrary"不匹配的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！