Tim Meyer
Tim Meyer

Reputation: 12600

MT / MD mismatch when compiling cryptopp despite no library dependencies

I'm currently trying to compile a static 64 bit version of cryptopp (more precisely, the cryptlib VS project) using MS Visual Studio 2013 on a Windows 8.1 machine. Since it is a static release build, I've set the Runtime Library to Multithreaded (/MT).

However the linker throws several of the following errors:

error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in adhoc.obj

In most of the similar cases I've found here and on google, this was caused by one library setting /MT and another one setting /MD. The weird thing about this case is that the linker does not include any libraries (except maybe some Visual-Studio-internal magic) and there are no additional include directories. The linker command line assembles as:

/OUT:"build\x64\static_release\cryptlib64.lib" /LTCG /MACHINE:X64 /NOLOGO

In the project file, I couldn't find any other <RuntimeLibrary> settings except for those on project level so I'd assume there is no .cpp file which has a /MD switch.

To sum it up, this means my library defines /MT, but something which is used by crytlib internally seems having /MD defined. Is there a way to find out what object/cpp/define/library/whatever has that switch defined?

Upvotes: 1

Views: 1715

Answers (3)

jww
jww

Reputation: 102205

The weird thing about this case is that the linker does not include any libraries (except maybe some Visual-Studio-internal magic)

There is a good chance that is where its coming from if you are certian its not something in your gear.

If Dynamic C++ Runtime Linking is an option for you, then you might consider using it for Crypto++. To ease the troubles of converting Crypto++ to Visual Studio 2010 (and above) and converting to /MD and /MDd, you can use vs2010-dynamic.zip. Just unpack it over top of the existing Crypto++ sources.


Also see Mismatch Detected for 'RuntimeLibrary' and Crypto++ on Stack Overflow.

Upvotes: 0

Emily Chen
Emily Chen

Reputation: 166

Cleaning the solution and then rebuilding might help. It seems the linker is still trying to use the old object files (before you applied /MT).

Upvotes: 1

Hans Passant
Hans Passant

Reputation: 941208

This linker diagnostic is a 100% accurate hint that you are in fact linking .obj or .lib files that were built wrong. Almost always .lib files that you don't know about because you didn't have to explicitly list them as Additional Dependencies. MSVC++ makes it pretty easy to specify link dependencies without having to use the setting, like using Add Reference or #pragma comment(lib, "yadayada.lib") in a source code file. Very convenient of course, but not so visible when you are trying to troubleshoot linker errors like this.

It is easily diagnosable however, the linker has an option to show you what it is actually linking. Use Project + Properties, Linker, Command Line and add the /VERBOSE option. The linker now gets very chatty to the Output window, showing you every .lib file it loads and what symbols it uses from the .lib file.

The .lib name should be enough of a hint to know where to start looking, you ought to know the #include from there. Whether you can really build with /MT is still up in the air, if it is an import library of a DLL then the odds dwindle rapidly. Avoid forcing it, having more than one copy of the CRT in a process is fraught with trouble.

Upvotes: 3

Related Questions