visual studio - Resolving LNK4098: defaultlib 'MSVCRT' conflicts with

Question

This warning:

LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts
  with use of other libs; use /NODEFAULTLIB:library

is a fairly common warning in Visual Studio. I'd like to understand the exact reason for it and the right way (if at all) to handle it.

This comes up in a debug build, compiled with /MDd. The project is linked to things like windows Version.dll and pdh.dll which themselves link with MSVCRT.dll. Obviously, I don't have the debug versions of these and can't compile them.

So I added /NODEFAULTLIB:MSVCRT to the linker command line and it actually did remove the warning. But what does this actually do? And why is it necessary?

Answer 1

There are 4 versions of the CRT link libraries present in vclib:

• libcmt.lib: static CRT link library for a release build (/MT)
• libcmtd.lib: static CRT link library for a debug build (/MTd)
• msvcrt.lib: import library for the release DLL version of the CRT (/MD)
• msvcrtd.lib: import library for the debug DLL version of the CRT (/MDd)

Look at the linker options, Project + Properties, Linker, Command Line. Note how these libraries are not mentioned here. The linker automatically figures out what /M switch was used by the compiler and which .lib should be linked through a #pragma comment directive. Kinda important, you'd get horrible link errors and hard to diagnose runtime errors if there was a mismatch between the /M option and the .lib you link with.

You'll see the error message you quoted when the linker is told both to link to msvcrt.lib and libcmt.lib. Which will happen if you link code that was compiled with /MT with code that was linked with /MD. There can be only one version of the CRT.

/NODEFAULTLIB tells the linker to ignore the #pragma comment directive that was generated from the /MT compiled code. This might work, although a slew of other linker errors is not uncommon. Things like errno, which is a extern int in the static CRT version but macro-ed to a function in the DLL version. Many others like that.

Well, fix this problem the Right Way, find the .obj or .lib file that you are linking that was compiled with the wrong /M option. If you have no clue then you could find it by grepping the .obj/.lib files for "/MT"

Btw: the Windows executables (like version.dll) have their own CRT version to get their job done. It is located in c:windowssystem32, you cannot reliably use it for your own programs, its CRT headers are not available anywhere. The CRT DLL used by your program has a different name (like msvcrt90.dll).