<t>There are 4 versions of the CRT link libraries present in vc\lib:<br/>
<br/>
- libcmt.lib: static CRT link library for a release build (/MT)<br/>
<br/>
- libcmtd.lib: static CRT link library for a debug build (/MTd)<br/>
<br/>
- msvcrt.lib: import library for the release DLL version of the CRT (/MD)<br/>
<br/>
- msvcrtd.lib: import library for the debug DLL version of the CRT (/MDd)<br/>
<br/>
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.<br/>
<br/>
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.<br/>
<br/>
/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.<br/>
<br/>
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"<br/>
<br/>
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).</t>
