Analysis on the conflicts between MFC library and CRT library

When the MFC library and the CRT library conflict, a LNK2005 error occurs. The specific errors are as follows:

Nafxcwd.lib (dllmodul.obj): Error LNK2005: [email protected] already defined in LIBCMTD.lib (dllmain.obj)

Nafxcwd.lib (afxmem.obj): Error LNK2005: "void * __cdecl operator new (unsigned int)" ([email protected]@z) already defined I n LIBCMTD.lib (new.obj)

Nafxcwd.lib (afxmem.obj): Error LNK2005: "Void __cdecl operator delete (void *)" ([email protected]@z) already defined in Lib CMTD.lib (Dbgdel.obj)

Nafxcwd.lib (afxmem.obj): Error LNK2005: "Void __cdecl operator delete[] (void *)" ([email protected]@z) already defined in L IBCMTD.lib (Delete2.obj)

Let's begin by understanding the information that is prompted in these errors:

Nafxcwd.lib,mfc static link library, debug version. (Release version is Nafxcw.lib)

LIBCMTD.lib, multi-threaded version of the CRT library.

The DllMain function is defined in both Dllmodul.cpp and Dllmain.cpp.

There is a standard implementation in the new, delete, DELETE[],CRT libraries, but the MFC is re-implemented again.

Then the above error means that the link has been LIBCMTD.lib, and then the link nafxcwd.lib will report the repeated definition of the error.

For Dllmain,new in MFC engineering, the DELETE function requires that the MFC library be linked first. The above error message shows that the project is a link to the LIBCMTD.lib before the error.

Version	Type	The library used	The library that was ignored	Note
R Release	Single Thread	LIBC.lib	LIBCMT.lib, MSVCRT.lib, LIBCD.lib, LIBCMTD.lib, Msvcrtd.lib
	Multithreading	LIBCMT.lib	LIBC.lib, MSVCRT.lib, LIBCD.lib, LIBCMTD.lib, Msvcrtd.lib	Lte
	Multithreading using DLLs	MSVCRT.lib	LIBC.lib, LIBCMT.lib, LIBCD.lib, LIBCMTD.lib, Msvcrtd.lib	Mdd
D Debug	Single Thread	LIBCD.lib	LIBC.lib, LIBCMT.lib, MSVCRT.lib, LIBCMTD.lib, Msvcrtd.lib
	Multithreading	LIBCMTD.lib	LIBC.lib, LIBCMT.lib, MSVCRT.lib, LIBCMTD.lib, Msvcrtd.lib	MT
	Multithreading using DLLs	Msvcrtd.lib	LIBC.lib, LIBCMT.lib, MSVCRT.lib, LIBCD.lib, LIBCMTD.lib	Md

Then, let's take a look at the link order of the project.

In the engineering properties->liner->general->show progress->for Libraries searched (if you want to see more detailed information optional Displayall Progress Messages).

The following information is displayed:

Searching libraries

Searching C:\ProgramFiles (x86) \microsoft Visual Studio 10.0\vc\lib\libcmtd.lib:

Searching C:\ProgramFiles (x86) \microsoft Visual Studio 10.0\vc\lib\oldnames.lib:

Searching C:\ProgramFiles (x86) \microsoft Visual Studio 10.0\vc\atlmfc\lib\nafxcwd.lib:

Nafxcwd.lib (dllmodul.obj): Error LNK2005: [email protected] already defined in LIBCMTD.lib (dllmain.obj)

Nafxcwd.lib (afxmem.obj): Error LNK2005: "void * __cdecl operator new (unsigned int)" ([email protected]@z) already defined I n LIBCMTD.lib (new.obj)

Nafxcwd.lib (afxmem.obj): Error LNK2005: "Void __cdecl operator delete (void *)" ([email protected]@z) already defined in Lib CMTD.lib (Dbgdel.obj)

Nafxcwd.lib (afxmem.obj): Error LNK2005: "Void __cdecl operator delete[] (void *)" ([email protected]@z) already defined in L IBCMTD.lib (Delete2.obj)

Searching C:\ProgramFiles (x86) \microsoft Sdks\windows\v7.0a\lib\kernel32.lib:

Searching C:\ProgramFiles (x86) \microsoft Sdks\windows\v7.0a\lib\user32.lib:

Searching C:\ProgramFiles (x86) \microsoft Sdks\windows\v7.0a\lib\gdi32.lib:

Searching C:\ProgramFiles (x86) \microsoft Sdks\windows\v7.0a\lib\msimg32.lib:

Search the order of the link library from the above, you can see that the first link LIBCMTD.lib, and then link nafxcwd.lib when the error.

Again, we open the *.vcproj project file and find information similar to the following

<ItemGroup>

<clcompile include= "Csi.c"/>

<clcompileinclude= "Log.cpp"/>

<clcompileinclude= "SOURCECODE\FTL\FLASHDRV_IF.C"/>

<clcompileinclude= "Sourcecode\ptl\usbdriver.c"/>

<clcompileinclude= "Stdafx.cpp" >

<precompiledheadercondition= "' $ (Configuration) |$ (Platform) ' = = ' debug| Win32 ' ">Create</PrecompiledHeader>

<precompiledheadercondition= "' $ (Configuration) |$ (Platform) ' = = ' release| Win32 ' ">Create</PrecompiledHeader>

</ClCompile>

<clcompileinclude= "U3_mlc.cpp"/>

</ItemGroup>

By the order of the above files, we can see that this order is sorted by the folder and file name by field.

The Csi.c file is ranked first by rule, so the order of the links is also up-to-date. Because it is a. c file, it must be programmed with the C compiler, which is bound to be the standard C library, or LIBCMTD.lib.

If we manually adjust the above engineering information as follows:

<ItemGroup>

<clcompileinclude= "Log.cpp"/>

<clcompile include= "Csi.c"/>

<clcompileinclude= "SOURCECODE\FTL\FLASHDRV_IF.C"/>

<clcompileinclude= "Sourcecode\ptl\usbdriver.c"/>

<clcompileinclude= "Stdafx.cpp" >

<precompiledheadercondition= "' $ (Configuration) |$ (Platform) ' = = ' debug| Win32 ' ">Create</PrecompiledHeader>

<precompiledheadercondition= "' $ (Configuration) |$ (Platform) ' = = ' release| Win32 ' ">Create</PrecompiledHeader>

</ClCompile>

<clcompileinclude= "U3_mlc.cpp"/>

</ItemGroup>

Let's look at the project's Search link order:

Searching libraries

Searching C:\ProgramFiles (x86) \microsoft Visual Studio 10.0\vc\atlmfc\lib\nafxcwd.lib:

Searching C:\ProgramFiles (x86) \microsoft Visual Studio 10.0\vc\lib\libcmtd.lib:

Searching C:\ProgramFiles (x86) \microsoft Visual Studio 10.0\vc\lib\oldnames.lib:

Searching C:\ProgramFiles (x86) \microsoft Sdks\windows\v7.0a\lib\kernel32.lib:

Searching C:\ProgramFiles (x86) \microsoft Sdks\windows\v7.0a\lib\user32.lib:

Searching C:\ProgramFiles (x86) \microsoft Sdks\windows\v7.0a\lib\gdi32.lib:

Searching C:\ProgramFiles (x86) \microsoft Sdks\windows\v7.0a\lib\msimg32.lib:

We can see that Nafxcwd.lib is the first to be searched for links, and the errors are gone.

Thus, by adjusting the order of the files in the. vcproj file, it is possible to affect the order of the links, which can resolve the errors of the MFC libraries and the link Order of the CRT libraries.

However, this method has a disadvantage, that is, if the next time you add. c files or. cpp non-MFC classes that do not have Kanenobu precompiled header files, and the file names are sorted at the top, this problem may still be raised again.

Microsoft provides a workaround for the above problem, build a Aa.cpp file, and then write a function like this:

int Test () {new int; return 1;}

Because of this file name, this file will naturally be first linked to, and linked to, the nafxcwd.lib. The manual adjustment of file order can be resolved.

It's kind of a trickery, but it feels weird.

In addition, there are people on the Internet to provide such a method:

Properties->liner->command line->additional Options:/force:multiple

For this setting, the MSDN introduction is

Use/force:multiple to create the output file whether or not LINK finds more thanone definition for a symbol.

A file created withthis option may not run as expected

In fact, this method is equivalent to forcing a link and ignoring the duplicate definition. And the above English also said, although the document was created, but not necessarily as expected.

So this method is not supposed to be used.

A lot of times, there is a library conflict, it will soon be thought to ignore the conflict database. But it's not right here. Because both of these conflicting libraries are to be used.

All online people have proposed this method, that is to start to Nafxcwd.lib two libraries; Libcmtd.lib are ignored, and then re-attach the two library Nafxcwd.lib; Libcmtd.lib.

Then, by looking at the link order, you can actually link correctly.

But, in fact, there is no need to be so complicated. All we need to do is make sure the Nafxcwd.lib is a priority link to this library. In fact, additional libraries are preferred for linking.

That is, add Nafxcwd.lib in the edit box after properties->liner->input->additional dependencies. This makes Nafxcwd.lib the first link.

Resources:

https://msdn.microsoft.com/en-us/library/72zdcz6f.aspx?f=255&MSPPError=-2147217396

https://support.microsoft.com/en-us/kb/148652

https://msdn.microsoft.com/zh-cn/library/70abkas3.aspx?f=255&MSPPError=-2147217396

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Analysis on the conflicts between MFC library and CRT library