Mismatch Detected for 'RuntimeLibrary'

Question

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.

To remedy that, I added C:\cryptopp\Win32\Output\Debug\cryptlib.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:\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

I also get:

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

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

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.

Solution 1

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

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

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. Multithreaded Debug
2. Multithreaded Debug DLL
3. Multithreaded Release
4. Multithreaded Release DLL

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.

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

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.

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

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.

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!

Solution 2

I had this problem along with mismatch in ITERATOR_DEBUG_LEVEL. As a sunday-evening problem after all seemed ok and good to go, I was put out for some time. Working in de VS2017 IDE (Solution Explorer) I had recently added/copied a sourcefile reference to my project (ctrl-drag) from another project. Looking into properties->C/C++/Preprocessor - at source file level, not project level - I noticed that in a Release configuration _DEBUG was specified instead of NDEBUG for this source file. Which was all the change needed to get rid of the problem.

Solution 3

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.

The conversion was probably not successful. The only thing that was successful was the running of VCUpgrade. The actual conversion itself failed but you don't know until you experience the errors you are seeing. For some of the details, see Visual Studio on the Crypto++ wiki.

---

Any ideas how to fix this?

To resolve your issues, you should download vs2010.zip if you want static C/C++ runtime linking (/MT or /MTd), or vs2010-dynamic.zip if you want dynamic C/C++ runtime linking (/MT or /MTd). Both fix the latent, silent failures produced by VCUpgrade.

---

vs2010.zip, vs2010-dynamic.zip and vs2005-dynamic.zip are built from the latest GitHub sources. As of this writing (JUN 1 2016), that's effectively pre-Crypto++ 5.6.4. If you are using the ZIP files with a down level Crypto++, like 5.6.2 or 5.6.3, then you will run into minor problems.

There are two minor problems I am aware. First is a rename of bench.cpp to bench1.cpp. Its error is either:

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

The fix is to either (1) open cryptest.vcxproj in notepad, find bench1.cpp, and then rename it to bench.cpp. Or (2) rename bench.cpp to bench1.cpp on the filesystem. Please don't delete this file.

The second problem is a little trickier because its a moving target. Down level releases, like 5.6.2 or 5.6.3, are missing the latest classes available in GitHub. The missing class files include 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.

The fix is to remove the missing source files from the Visual Studio project files since they don't exist for the down level releases.

Another option is to add the missing class files from the latest sources, but there could be complications. For example, many of the sources subtly depend upon the latest config.h, cpu.h and cpu.cpp. The "subtlety" is you won't realize you are getting an under-performing class.

An example of under-performing class is BLAKE2. config.h adds compile time ARM-32 and ARM-64 detection. cpu.h and cpu.cpp adds runtime ARM instruction detection, which depends upon compile time detection. If you add BLAKE2 without the other files, then none of the detection occurs and you get a straight C/C++ implementation. You probably won't realize you are missing the NEON opportunity, which runs around 9 to 12 cycles-per-byte versus 40 cycles-per-byte or so for vanilla C/C++.

Solution 4

Issue can be solved by adding CRT of msvcrtd.lib in the linker library. Because cryptlib.lib used CRT version of debug.

View more solutions

Comments

[us2012]

msdn.microsoft.com/en-us/library/6wtdswk0%28v=vs.71%29.aspx msdn.microsoft.com/en-us/library/2kzt1wy3(v=vs.71).aspx bugzilla.mozilla.org/show_bug.cgi?id=732124

[Momonga]

I set my project's runtime library to Multi-threaded debug (that was the setting used in crypto++) and now it compiles! :) Thank you so much.

[jww]

The problems occurred much earlier when you ran VCUpgrade. You are seeing symptoms of the VCUpgrade failure that was reported as a Success to you.

[Admin]

I am a bit confused. OP's error is LNK2038. As it does not happen with all libs, I suspect Crypto++ fiddles with some CRT settings that make it impossible to mix CRT flavours - usually it is just a warning (LNK4098) and you may be safe if you know what you do (not recommended, but possible with limitations, see e.g. stackoverflow.com/a/19944935/948581). I don't know why Crypto++ is affected this way, though.

[yzt]

@Tibo: These are not import libraries for DLLs; I believe Crypto++ is actually being linked statically with the program here. This means that any mismatch in the standard library being linked with in one module against another (probably) violates the "One Definition Rule". Which is bad. This used to be not an error, since the linker wasn't even able to detect this (the function/type names were the same, but their bodies and definitions differed significantly) until VC10 when the linker/librarian started "tagging" the modules it produced with extra information about the config of the build...

[yzt]

@Tibo: ... (continued from previous comment) For example, look at the first block of errors the OP is reporting. In there, "RuntimeLibrary" is a tag on both the Crypto++ library and the object file for the OP's program, and its value is "MDd_DynamicDebug" for one of them and "MTd_StaticDebug" for the other. This way, the linker that is trying to link two object files together can detect and report a whole new class of errors, given that the linkers that produced those object files tagged them with any relevant information, particularly any settings that would potentially violate ODR.

[Admin]

While I quite agree with you, there is still an area of mystery here. As for the OP's problem, I guess he is including "dll.h" from Crypto++, and then tries to link against the static lib instead of the DLL's import library. But I've seen the exact same errors on one computer, not on another one (VS2013 ultimate sp4 -> error, VS2013 community sp5 -> ok)...

[Admin]

... (continued) I'm ready to bet the build system of Crypto++ is broken and may produce invalid binaries if you don't compile the libs (static and DLL) in the correct order (and I've also seen new/delete oddities and a potentially failing post-build step). Other than that, VC2010 introduced a way of reporting/trapping these errors, sure, but the sole CRT mismatch doesn't (totally) explain the error. Weird.

[yzt]

@Tibo: Hmmm... I can't say I'm in any way familiar with Crypto++'s build system. However, this answer ("simply linking against the correct runtime") seems to have helped many people, so I don't see evidence for anything rotten on Crypto++'s side. But again, I'm not familiar with that at all. It has always "Just Worked" for me on the first build.

[Yttrill]

I am still very confused. I have this problem static linking. VS actually complains about a string in an object file which is nonsense. There is only a single link operation, and it is only at link time that the library to link against is chosen with /MT or /MTd. This looks like a totally incompetent design in their system. The static libraries I am linking against are mine but they could have been supplied by anyone.

[Yttrill]

Maybe nonsense .. but that's what it does. /MT(d) or /MD(d) put stuff in object file.

[Yaniv]

I followed the instructions in the cryptopp wiki, downloaded vs2010-dynamic.zip and pasted it's contents onto the cryptopp563 code. Built and got some source files missing. No problem the wiki says the zip is for the latest project on github, and just delete any missing files. Deleted. Now the project just doesn't build: 4 link errors, one example: error LNK2001: unresolved external symbol "void __cdecl OutputResultOperations(char const *,char const *,bool,unsigned long,double)" (?OutputResultOperations@@YAXPBD0_NKN@Z)

[Yaniv]

Turned out there was a bench.cpp that was missing from the project. But even after that it did not compile until I applied this fix to fiptest.cpp github.com/weidai11/cryptopp/pull/151/files?diff=split I wish they would make some order in this, like add the project zip files into git or something. And yes, I neglected to say my compiler is VS2015 update 2. Bottom line, follow the hints I wrote and it works.

[jww]

@Yaniv - For the first comment, what do you recommend so other users don't experience problems? For the second comment, we plan on taking the patch once we get it fully tested. Is there anything we can do in the meantime? (I added additional info to this answer, but I want to ensure users don't have trouble).

[Yaniv]

Firstly, thanks so much for doing this. Crypto++ really rocks. Regarding the build problems, try to keep the windows sln and project files compatible with the latest files in the project, and since these change of course, these windows build should be somehow linked to the codebase, and maybe even be on the source tree. If that is too much, at least make sure the zip file with the visual studio build environment is compatible with the current stable official release.

[Yaniv]

Regarding the patch for fiptest.cpp - it seems to be something different about VS2015, so I guess anyone wishing to use VS2015 needs to apply this patch. It's just another case in an #ifdef block that seems to define the right debug callback for VS2015, and it's really easy to patch manually.

[Sahil Singh]

What is happening behind the scenes? Why can't a library compiled with /MT be linked to a program being compiled with /MD, after all /MT, and /MD only are concerned with the runtime library, any other library should be fine.

[Sahil Singh]

Thanks, I do agree with what you said. I had the notion that /MT and /MD only change the way the runtime is linked with a project, but the version of runtime remains the same. i.e. if VC++ links runtime-1.0 (say) statically when using /MT, then if I select /MD then during run time of the project, the same runtime-1.0 will be linked to it dynamically (I thought the compiler would add some meta data about runtime version). Since runtime-1.0 is being used in both the cases, hence no incompatibility of the nature mentioned by you.

[Sahil Singh]

I am in the process of modifying a large solution. One of the projects in the solution has to use WinRT (/ZW compiler option). /ZW requires projects to be compiled with /MD. Thus when this projects tries to link with other projects compiled with /MT, it causes compilation error. One option is to convert all projects to use /MD, but then we also have some code compiled by other teams. They just give us lib files (compiled with /MT), and we can't tell all other teams to suddenly start using /MD.

[yzt]

@SahilSingh: I haven't worked with WinRT, so if there is specific workaround, I'm unaware of it. However, you probably can disable (or silence) the link error discussed here, but you'll risk runtime crashes, or worse, silent memory corruption and/or malfunction. There are possible scenarios that this would work out, e.g. if those other libs are pure C code (and only accept/return simple data, and lifetime and ownership of all heap objects are cleanly separated, etc.) Test thoroughly if you do that. The best solution I know of is building all your libraries with the same runtime library.

[Sahil Singh]

@yzt I figured out a solution. Instead of using /ZW swicth, windows provides a way to use WinRT API via COM using a wrapper called WRL. It is just that not using /ZW makes coding little difficult since it hides COM implementation details, but it is possible to use WinRT without /ZW.

[Mr00Anderson]

Edit 2019: This fixed it for me. Microsoft was trying dynamically include the library while from my cmake it was static. # Prevent overriding the parent project's compiler/linker # settings on Windows # https://github.com/google/googletest/blob/master/googletest/‌​README.md set(gtest_force_shared_crt ON CACHE BOOL "" FORCE)