error LNK2005: _DllMain@12 already defined in MSVC

问题:

I am getting this linker error.

mfcs80.lib(dllmodul.obj) : error LNK2005: _DllMain@12 already defined in MSVCRT.lib(dllmain.obj)

Please tell me the correct way of eliminating this bug. I read solution on microsoft support site about this bug but it didnt helped much.

I am using VS 2005 with Platform SDK

回答1:

If you read the linker error thoroughly, and apply some knowledge, you may get there yourself:

The linker links a number of compiled objects and libraries together to get a binary.

Each object/library describes

• what symbols it expects to be present in other objects
• what symbols it defines

If two objects define the same symbol, you get exactly this linker error. In your case, both mfcs80.lib and MSVCRT.lib define the _DllMain@12 symbol.

Getting rid of the error:

1. find out which of both libraries you actually need
2. find out how to tell the linker not to use the other one (using e.g. the tip from James Hopkin)

回答2:

I had the same error message, but none of the answers here solved it for me. So if you Encounter that Problem when creating a DLL Project that uses MFC, it can be resolved by entering the following line:

extern "C" { int _afxForceUSRDLL; } 

to the cpp file where DllMain is defined. Then your own DllMain implementation is used, rather than the one from dllmain.obj.

When we try to use MFC library, we surely will include afx.h directly or indirectly, then MFC(afx.h) tell the linker to find the symbol of __afxForceUSRDLL and put that object which contains __afxForceUSRDLL into the program, so linker searches and puts dllmodule.obj into our program, because __afxForceUSRDLL is defined in dllmodule.cpp.

That’s the common scenario. When we want to use our own DllMain in a mfc dll project, linker complains that there are two DllMain, one in our code, one in Dllmodule.obj.

So we need to tell the linker to add our dllmain.obj for __afxForceUSRDLL. So we need to define __afxForceUSRDLL in our own cpp file where our own DllMain is defined, then the linker will ignore mfc’s dllmodule.obj and see only one DllMain and never complains.

Source: http://social.msdn.microsoft.com/Forums/en-US/0d78aa6b-1e87-4c01-a4a7-691335b7351a/how-to-build-mfc-application-dll-in-visual-c-2010

回答3:

If you're defining your own DllMain, in your project settings you need to set 'Use of MFC' in the 'Configuration Properties/General' to 'Use Standard Windows Libraries'.

You should do a clean rebuild after changing it.

回答4:

In my project I was able to solve this problem by adding mfcs80.lib and msvcrt.lib as additional dependencies in the project settings. The 'additional dependencies' can be found under Linker -> Input.

In the debug configuration that would have to be mfcs80d.lib and msvcrtd.lib respectively.

By the way, I am working with Visual Studio 2010, so in my case the MFC lib is called mfc100.lib.

I am not sure why this worked. It is not necessary to add these lib files as additional dependencies because I already set 'Use of MFC' to 'Use MFC in a shared dll'. I guess that by specifying these libraries as additional dependencies they are linked in a different order.

This solution is more or less the same as the one suggested on the Microsoft site: http://support.microsoft.com/kb/148652, except I did not need to type anything in the 'Ignore specific default libraries' box.

回答5:

For me the direct cause was indeed a missing _afxForceUSRDLL symbol reference, but the indirect cause was a missing _USRDLL macro definition. It is defined by default by the VC wizard, but occasionally devs erase it erroneously. Here it is in more words.

回答6:

MSDN knowledge base ID Q148652.

http://support.microsoft.com/kb/148652

Cause: Visual C++ compiles the source files in alphabetical order, and passes the compiled object files to the linker in alphabetical order. If the linker processes DLLDATAX.OBJ first, the source code references DllMain, which the linker loads from MSVCRTD.LIB(dllmain.obj). The linker then processes an object file compiled from a C++ file that contains #include "stdafx.h", which references the symbol __afxForceUSRDLL, which the linker loads from MFC42D.LIB(dllmodul.obj). This object module also contains an implementation for DllMain, causing the conflict.

回答7:

For all those who are experiencing this error in ATL projects (mostly when trying to add MFC support), here's the solution I found after days of frustration!

First of all, this link was more helpful to me than all the others. It pointed me into the right direction. The problem occurs, if the "generated files" (containing the proxy and stub code, just as the type guids) for some reason have been removed and readded to the project. This causes Visual Studio to add them in the wrong order!

Usually you first come up with the "ATL requires C++ compilation" error, but you may have fixed this by turning out the Yc/Yu (precompiled headers) setting for that file.

What you should do next is unloading your project and edit it. Search for the item groups that define the build and include order (ClCompile and ClInclude). Check their order and settings.

The compiles should appear in this order:

1. dllmain.cpp (with CompileAsManaged set to false and PrecompiledHeader left empty).
2. Library source (MyLib.cpp, containing DllCanUnloadNow and so on)
3. Proxy/Stub code (MyLib_i.c; with same settings as dllmain.cpp)
4. stdafx.cpp (with PrecompiledHeader set to Create)
5. All the other library source files (your actual libraries content)
6. xdlldata.c (with the same settings as dllmain.cpp)

The includes should then be ordered like this:

1. dllmain.h
2. MyLib_i.h
3. Resource.h
4. stdafx.h
5. targetver.h
6. ... (actual library headers)
7. xdlldata.h

Fixing the build order fixed my project and I was able to create a new clean build.

回答8:

I have a very similar problem. [mfcs110d.lib(dllmodul.obj) : error LNK2005: _DllMain@12 already defined in MSVCRTD.lib(dllmain.obj)] and the solution was add mfcs110d.lib to Additional Dependencies

回答9:

In my case I had a problem with the preprocessor directives. For some reason _USRDLL was defined, when it should not have been.

To check this, go to the menu Project , select Project Properties , then select the snippet Configuration Properties --> Preprocessor .

The preprocessor directives will be found there.

回答10:

I have personally got rid of this error this way: right-clicked project in the Solution Explorer, selected Properties from pop-up menu, clicked Linker tab and added mfcs71ud.lib into Additional Dependencies. If you're using Visual Studio 2005, it should be "80" instead of "71" and so on.

回答11:

Just #undef the _USRDLL before including afx.h, or even better, edit your project configuration and remove the macro.

This is the usual configuration for a MFC extension DLL: Build Settings for an MFC DLL

回答12:

I found solution Here Visual Studio 2010 library linking order

this is: /FORCE:MULTIPLE in linker options

I had to mix ATL and MFC together , to use [module(name = "mymodule")]; construction in MFC application together with "__hook" keyword

回答13:

I found this which helped me: http://support.microsoft.com/kb/148652

Basically the linker order was incorrect. the CRT libs were getting linked before the MFC libs. Turns out, the MFC libs had to get linked FIRST, and then the CRT libs could be linked.

Yucko Microsoft!!

回答14:

Declare the mfc80ud.lib and mfcs80ud.lib in the Additional Dependancies field in the Project Properties -> Linker Tab -> Input of Visual Studio to fix the issue.

回答15:

Make sure you include "Stdafx.h" at the top of each .cpp file. I was getting the exact same error and had a single .cpp file that did not include this header at all. Adding the #include solved the problem.