Choosing the Correct C/C++ Runtime Library

The C/C++ runtime library contains basic functions like memory allocation (malloc, new), output (printf), and string manipulation (strcpy, strlen).

When building a C/C++ application or library, you must pick a C/C++ runtime library. In Visual Studio 2005, you can select this option using Project->Properties...->Configuration Properties->C/C++->Code Generation->Runtime Library:

You have 4 versions:

1. Multi-threaded (/MT)
2. Multi-threaded Debug (/MTd)
3. Multi-threaded DLL (/MD)
4. Multi-threaded DLL Debug (/MDd)

The C++ runtime library is dependent on the C runtime library. The C runtime library version must match the C++ runtime library version.  Thus, these options apply to both the C and C++ runtime libraries.

In previous versions of Visual Studio, you had additional options that were single-threaded. These versions would execute faster on a single core than the multi-threaded versions. However, they were not safe to use in a multi-threaded application. I'm guessing these libraries were dropped since multiple cores are quickly becoming ubiquitous and multi-threaded applications are needed to take advantage of these extra cores.

These four choices are all the permutations from two variables:

• Debug vs. Release
• DLL vs. Static Library

The first variable is easy. Use Debug on internal software that is not shipped to customers. The debug runtime library *can't* be included with your application legally. Just to be clear, you *can* ship a debug version of your application to a customer, but it should use the *release* version of the runtime library.

The Debug runtime library gives you access to some helpful debugging aids for error reporting and tracking down memory leaks. See the additional debug functionality you get with this version of the runtime library (and macro _DEBUG defined) here.

The next variable is DLL or Static Library. In general, you should use DLL. You might consider the Static Library version if:

• You have a small application and you don't want to waste memory with runtime library calls you don't need
• You want a simple application that is not dependent on shipping with an additional runtime library DLL.

The above instructions work well if your application doesn't use any other libraries. That rarely happens. Microsoft has several vague warnings in their documentation about using more than one version of runtime in an application.

The goal is to use one runtime library throughout your entire application.

That is nearly impossible since you typically don't have control of which runtime library other libraries use. For example, OpenGL uses the runtime library. If your application or any other libraries you use don't use the same runtime library as OpenGL, then you are mixing runtime libraries.

How do you know what runtime library a .EXE, .DLL or shared library (.LIB), or .OBJ use? Use this command line:

dumpbin /all XXXX | find /i "msvcr"

...and replace XXXX with the .EXE, .DLL, .LIB (for static libraries...not the stub for .DLL's), or .OBJ in question. You should get something similar to this:

You can use the results from this command with this page to see which runtime library you should use.

If you don't get any output, then it likely means that a static runtime library is used.

Even with information about what runtime libraries are in use, you may find it impossible to make your application use a single runtime library. If you match the runtime libraries, it is possible that one library uses the Visual Studio 7.0 version of the runtime library (msvcr70.dll) but you only have access to Visual Studio 8.0 (msvcr80.dll).

So now what?

It turns out is is OK to mix runtime libraries *except* in certain cases. A well written library should avoid these cases and then it doesn't matter if the runtime libraries match. Libraries that cannot avoid these cases should ship with 4 versions of their libraries that match the 4 versions of the runtime libraries.

Here is a good article with examples of situations to avoid so that you don't have to worry about mixing runtime libraries.

Choosing a runtime library summary...

• Use the debug version only internally, release for anything that could be used by customers
• Use the DLL version except in special situations
• Use consistent settings throughout your project (the runtime library setting can be done per source file)
• Don't worry if your runtime library settings match other libraries you use (unless the library comes in multiple runtime library versions)