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?

Ottie

First of all: make sure you are referencing matching version of dependent libraries. In many cases your Debug config should reference somethingd.lib and the Release should reference something.lib at the same time. – Juta

Answer 1

There are 4 versions of the CRT link libraries present in vc\lib:

• 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 compiled with /MD. Not valid, 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:\windows\system32, 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).

Whopper

Thanks to this post, I kept looking for a .lib that was still using /MDd and I eventually found one! Thanks, +1 – Mcgough

An trick I just learned to track down libraries that are pulling in the wrong CRT libraries is to add /verbose:lib to the additional linker options. It shows the order that .lib files are loaded in, allowing you to see where the incorrect one was pulled in. – Famulus

Hans, how dangerous is it? If we cannot fix it (we get a compiled lib from our vendor), what consequences we may face? – Descender

@IvanNikitin You may want to fully read the link Yochai Timmer posted : mygoldenchariot.blogspot.ca/2006/07/… If you find it hard to read like I did, you can always read my summary : https://mcmap.net/q/100272/-resolving-lnk4098-defaultlib-39-msvcrt-39-conflicts-with – Mroz

"find the .obj or .lib file that you are linking that was compiled with the wrong /M option.", and then do what. – Contracture

I found @obmarg' comment useful but still wasn't sure how to use the verbose output until I found msdn.microsoft.com/en-us/library/aa267384(v=vs.60).aspx which says the verbose output will only tell you all the runtime libraries involved in the link problem. You still have to then figure out which link input has been compiled with the conflicting Runtime Library. – Modigliani

Is it safe to build a release static library with /MD and then link it with a debug application that uses /MDd? – Curtate

@Modigliani use /verbose instead of /verbose:lib. The displayed information includes the library search process and lists each library and object name (with full path), the symbol being resolved from the library, and a list of objects that reference the symbol. /verbose can display all the info you need to find the bad guy that causes the conflicts. – Arbil

Answer 2

It means that one of the dependent dlls is compiled with a different run-time library.

Project -> Properties -> C/C++ -> Code Generation -> Runtime Library

Go over all the libraries and see that they are compiled in the same way.

More about this error in this link:

warning LNK4098: defaultlib "LIBCD" conflicts with use of other libs

Multiplex

That was the reason of the error! Thanks for the tip. – Sideman

This is the best answer for less experienced programmers. – Allegiance

Answer 3

IMO this link from Yochai Timmer was very good and relevant but painful to read. I wrote a summary.

Yochai, if you ever read this, please see the note at the end.

---

For the original post read : warning LNK4098: defaultlib "LIBCD" conflicts with use of other libs

Error

LINK : warning LNK4098: defaultlib "LIBCD" conflicts with use of other libs; use /NODEFAULTLIB:library

Meaning

one part of the system was compiled to use a single threaded standard (libc) library with debug information (libcd) which is statically linked

while another part of the system was compiled to use a multi-threaded standard library without debug information which resides in a DLL and uses dynamic linking

How to resolve

• Ignore the warning, after all it is only a warning. However, your program now contains multiple instances of the same functions.

• Use the linker option /NODEFAULTLIB:lib. This is not a complete solution, even if you can get your program to link this way you are ignoring a warning sign: the code has been compiled for different environments, some of your code may be compiled for a single threaded model while other code is multi-threaded.

• [...] trawl through all your libraries and ensure they have the correct link settings

In the latter, as it in mentioned in the original post, two common problems can arise :

• You have a third party library which is linked differently to your application.

• You have other directives embedded in your code: normally this is the MFC. If any modules in your system link against MFC all your modules must nominally link against the same version of MFC.

For those cases, ensure you understand the problem and decide among the solutions.

---

Note : I wanted to include that summary of Yochai Timmer's link into his own answer but since some people have trouble to review edits properly I had to write it in a separate answer. Sorry

Mroz

Answer 4

I get this every time I want to create an application in VC++.

Right-click the project, select Properties then under 'Configuration properties | C/C++ | Code Generation', select "Multi-threaded Debug (/MTd)" for Debug configuration.

Note that this does not change the setting for your Release configuration - you'll need to go to the same location and select "Multi-threaded (/MT)" for Release.

Expectorate

Answer 5

Right-click the project, select Properties then under 'Configuration properties | Linker | Input | Ignore specific Library and write msvcrtd.lib

Limnetic

Answer 6

This warning was fixed for me when no library in the project was included twice. In my case it was in the source file with #pragma comment, and in project property page: Linker -> Input -> Additional Dependencies

Welton