error LNK2005: _DllMain#12 already defined in MSVCRT.lib - c++

Question

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

Answer 1

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

Answer 2

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:
find out which of both libraries you actually need
find out how to tell the linker not to use the other one (using e.g. the tip from James Hopkin)

Answer 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.

Answer 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.

Answer 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.

Answer 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.

Answer 7

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

Answer 8

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:
dllmain.cpp (with CompileAsManaged set to false and PrecompiledHeader left empty).
Library source (MyLib.cpp, containing DllCanUnloadNow and so on)
Proxy/Stub code (MyLib_i.c; with same settings as dllmain.cpp)
stdafx.cpp (with PrecompiledHeader set to Create)
All the other library source files (your actual libraries content)
xdlldata.c (with the same settings as dllmain.cpp)
The includes should then be ordered like this:
dllmain.h
MyLib_i.h
Resource.h
stdafx.h
targetver.h
... (actual library headers)
xdlldata.h
Fixing the build order fixed my project and I was able to create a new clean build.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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

Answer 13

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.

Answer 14

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

Answer 15

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!!

Answer 16

There is a common theme running through some of the answers here.
Avishek Bose:-
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.
vmb100:-
I am working with Visual Studio 2010, so in my case the MFC lib is
called mfc100.lib.
joseAndresGomezTovar:-
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
So the general case seems to be to first find the name of the library to add ...
and then to add it ....
Note that there seem to be some prerequisites and/or alternative solutions.

Answer 17

This can also occur if your solution has multiple projects that export the same symbols. For example if you have sub-project that builds foo.dll with a foo.def file that exports DoFoo and a sub-project for bar.dll with a bar.def file that exports DoFoo, a collision will occur and this is the error you will see when you link.