1

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?

Tim Meyer
  • 12,210
  • 8
  • 64
  • 97
  • 3
    You can pretty safely assume that it *does* link other libraries. Probably instructed to do so by a #pragma comment somewhere in the source code. Usually also a strong hint that only /MD is going to work. Use the /VERBOSE linker option, you'll see the libraries getting loaded and searched. – Hans Passant Feb 10 '15 at 09:52
  • There are indeed some pragmas for library inclusions which helped me find out which preprocessor definitions I made wrong. Make your comment an answer and I'll accept it. – Tim Meyer Feb 10 '15 at 12:08
  • `/LTCG` also places some restrictions on things. I've had a problem in the past using it with Crypto++. I *think* the work around was to re-compile the Crypto++ static library using dynamic C Runtime linking. (By default, the Crypto+ static library is built using static C Runtime linking. Hence the reason for the issues with the use of `/MT` and `/MD`). – jww Feb 16 '15 at 00:19

3 Answers3

3

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.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
1

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

Emily Chen
  • 159
  • 1
  • 10
  • This occurred on the very first build, unfortunately – Tim Meyer Feb 10 '15 at 11:53
  • Then unfortunately my answer was irrelevant. But since the error message says "adhoc.obj", something by the name "adhoc" is probably the library in question. It appears the library file is not compiled to be used as a static library. – Emily Chen Feb 10 '15 at 15:26
0

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.

Community
  • 1
  • 1
jww
  • 97,681
  • 90
  • 411
  • 885