249

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?

Edgar Rokjān
  • 16,412
  • 4
  • 37
  • 63
shoosh
  • 70,450
  • 50
  • 199
  • 310

5 Answers5

296

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

Hans Passant
  • 873,011
  • 131
  • 1,552
  • 2,371
  • 3
    Thanks to this post, I kept looking for a .lib that was still using /MDd and I eventually found one! Thanks, +1 – ceztko Nov 09 '11 at 16:04
  • 71
    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. – obmarg Mar 13 '13 at 12:18
  • 1
    Hans, how dangerous is it? If we cannot fix it (we get a compiled lib from our vendor), what consequences we may face? – Ivan Nikitin Aug 25 '13 at 13:56
  • 1
    @IvanNikitin You may want to fully read the link Yochai Timmer posted : http://mygoldenchariot.blogspot.ca/2006/07/link-warning-lnk4098-defaultlib-libcd.html If you find it hard to read like I did, you can always read my summary : http://stackoverflow.com/a/20650130/62921 – ForceMagic Dec 18 '13 at 05:14
  • "find the .obj or .lib file that you are linking that was compiled with the wrong /M option.", and then do what. – basickarl Dec 07 '14 at 05:26
  • 5
    I found @obmarg' comment useful but still wasn't sure how to use the verbose output until I found http://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. – buzz3791 Jan 12 '15 at 15:09
  • Is it safe to build a release static library with `/MD` and then link it with a debug application that uses `/MDd`? – Violet Giraffe Jul 24 '16 at 20:18
  • 7
    @buzz3791 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. – Yang Kui Feb 11 '17 at 08:20
53

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

Bridge
  • 27,772
  • 8
  • 56
  • 78
Yochai Timmer
  • 44,746
  • 21
  • 135
  • 179
33

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

Community
  • 1
  • 1
ForceMagic
  • 5,535
  • 11
  • 62
  • 83
8

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.

user1016736
  • 380
  • 4
  • 6
6

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

raehee
  • 69
  • 2
  • 7