I am working on a project using c++/windows forms (visual studio 2010), we have 4 projects:
1 project containing GUI windows forms {managed code} and this is the exe project
other 3 projects {non-managed code} and all are static libraries.
in the 4 projects we don`t use precompilied headers stdafx.h , and common language runtime support is the Pure MSIL Common Language Runtime Support (/clr:pure).
every project include the other 3 projects as additional include directories , and link library dependencies set to yes.
We have:
Warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library
This warning appeared for the 3 static libraries projects in the same object files (.NETFramework,Version=v4.0.AssemblyAttributes.obj).
We want to eliminate it, but after some search, most topics speak about the precompiled headers to be a reason while we don not use it.
Any new ideas about why this warning exist and how to eliminate it?
Disclaimer: This solution is indeed terrible, and this code should not be added to production build! It is only useful to "hide" the warning.
A better solution would be to remove the file in question from the compilation, as it is anyway useless.
Original post:
I had a the problem with this warning originating from several dependencies, and I found that it was caused by some translation unit being empty, i.e. empty source files.
These files actually had a content but it was deactivated for visual studio so I just added at the beginning:
__declspec( dllexport ) void getRidOfLNK4221(){}
And now my project compiles without any warning :)
Hope it helps, even if this is a late answer!
I had a c++ static library with an empty module in it, linking which in non-optimized mode gave me that LNK4221 warning. (in Visual Studio)
I went to Librarian->All Options, and added "/ignore:4221" to Additional Options.
So, the warning has disappeared.
You get this warning because you use only template classes in cpp file.
To get rid of it, insert one simple function with no template.
See this:
https://learn.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-warning-lnk4221
In summary, the file exports nothing, so linker does not link, as it thinks it's a waste of effort
This was kind of just my particular problem but if your .cpp doesn't define any new functions or has empty bodies for constructor functions, you will get this warning. I used an initialization list for my constructor so the body was empty.
https://devblogs.microsoft.com/cppblog/linker-warning-lnk4221-and-some-tips-to-avoid-it/
In ” Visual Studio 2008 Command Prompt”, enter the following commands (Note: We use command line here to specify the order of .obj files; Visual Studio 2008 will supply linker with .obj files in alphabetical order)
cl /c a.cpp b.cpp
link /lib /out:test.lib a.obj b.obj
And LNK4221 will be thrown for a.obj as the following.
a.obj : warning LNK4221: no public symbols found; archive member will be inaccessible
For the above case, atlbase.h (shipped with Visual Studio) contains some definitions of symbols, which will be included in both a.obj and b.obj. Additionally, there is a function, func1, defined in b.obj. Linker will process OBJ files in Last In First Out manner, so when it is processing a.obj, it cannot find any new public symbols in it because b.obj provide all the public symbols that a.obj has, LNK4221 will be thrown. If command line 2 is replaced with following
link /lib /out:test.lib b.obj a.obj
Now the warning is gone!
Related
I've just been beaten (rather hardly) on the head by some non-trivial warning from Visual Studio 2010 (C++).
The compilation gave the following output:
1 Debug\is.obj : warning LNK4042: object specified more than once; extras ignored
1 Debug\make.obj : warning LNK4042: object specified more than once; extras ignored
1 Debug\view.obj : warning LNK4042: object specified more than once; extras ignored
1 identity.obj : error LNK2019: unresolved external symbol void __cdecl
test::identity::view(void) (?view#identity#test##YAXXZ) referenced in function void __cdecl test::identity::identity(void) (?identity#0test##YAXXZ)
1 identity.obj : error LNK2019: unresolved external symbol void __cdecl test::identity::make(void) (?make#identity#test##YAXXZ) referenced in function void __cdecl test::identity::identity(void) (?identity#0test##YAXXZ)
1 range.obj : error LNK2019: unresolved external symbol void __cdecl test::range::is(void) (?is#range#test##YAXXZ) referenced in function void __cdecl test::range::range(void) (?range#0test##YAXXZ)
Linker errors are always a pain to debug... but there were unresolved references, and so I checked... but the source is well-formed... and finally it hit me:
My folder hierarchy looks like so:
src/
identity/
is.cpp
make.cpp
view.cpp
range/
is.cpp
make.cpp
view.cpp
and so does the hierarchy in the Solution (I always set it up so that it mimicks the "real" folder structure).
And the diagnostic outputs:
Debug\is.obj
Debug\make.obj
Debug\view.obj
Along with a warning which says that the .obj has been passed twice to the linker and that one will be ignored.
Search no more: Visual has neatly flatten my folder hierarchy, and therefore is unable to neatly compile the source.
At the moment, I am simply thinking of renaming the files, that should cover the issue...
... but is there a way to have Visual Studio NOT flatten the file hierarchy ?
I had a similar problem with linker warning LNK4042: object specified more than once; extras ignored. In my case Visual Studio was trying to compile both header and source files with the same name - MyClass.h and MyClass.cpp. It happened because I renamed .cpp file to .h and Visual Studio got confused. I noticed the problem by looking at the compiler logs in the Debug directory. To resolve just remove .h file from the project then add it again.
Just wanted to cross post what I believe to be the answer, if you open the properties for the entire project, and the change the value under C/C++ -> Output Files -> "Object File Name" to be the following:
$(IntDir)/%(RelativeDir)/
Under VS 2010, I believe this will disambiguate all of the object files (as I believe windows won't let you under any crazy circumstances have two files with the same names in the same directory). Please also check out the details here.
Right-click the .cpp file in the Solution Explorer window, Properties, C/C++, Output Files, Object File Name setting. The default is $(IntDir)\, that's what is doing the flattening. All the .obj file will go into $(IntDir), the "Debug" directory in the debug configuration.
You can change the setting, say $(IntDir)\is2.obj. Or select all the files from one group (use Shift+Click) and change the setting to, say, $(IntDir)\identity\
Or you can change the .cpp filename so that .obj files don't overwrite each other. Having files with the exact same name in two directories is a bit odd.
Or you can create multiple projects, creating, say, .lib projects for the files in identity and range. Commonly done in makefile projects for example. That does however make managing the compile and link settings more of a hassle unless you use project property sheets.
Right click on header file -> Property -> ItemType (select C/C++ Header). Do the same with Cpp file but select C/C++ Compiler (it's work for me)
Alternatively to deleting and making a new file you can change the compile/include settings.
Go to your project.vcxproj file, open it with an editor, find the html like line <ItemGroup>.
It should look something like:
<ItemGroup>
<ClCompile Include="implementation.cpp" />
</ItemGroup>
and
<ItemGroup>
<ClInclude Include="declaration.hpp" />
</ItemGroup>`
Assuming your implementation files are .cpp and your declarations are .hpp. Make sure your all your implementation files are listed between the first section if you have more then one and likewise for the second section for multiple declaration files.
I had this problem with stdafx.cpp. Somehow stdafx.cpp got duplicated, so there was a second StdAfx.cpp (mind the different case).
After I removed the StdAfx.cpp everything worked fine!
Using VS 2010.
I use $(IntDir)\%(Directory)\ under C/C++ -> Output Files -> "Object File Name".
I used to have in the same project .c and .cpp files with the same filenames. The files were in folders all over the place and the solutions provided by others created a mess, and folder hell (in my case). Even Release builds would overwrite Debug builds!
A good (not perfect) solution would be to use $(ParentName), but for some reason beyond anyone's grasp it has been removed from later versions of Visual Studio (2015+).
What I use succesfully now is:
$(IntDir)%(Filename)%(Extension).obj
which at least separates .c built object files from .cpp.
I'd like to point out one possible reason for why the ItemType of a .h file would change from C/C++ header to C/C++ compiler:
In the Solution Explorer window of VS (2019 here), right click the project name, choose Add -> New Item;
Select the C++ File (.cpp) template, but type something.h in the name input area, then click OK to add it;
Then you'll encounter the LNK4042 warning if the something.h file be included within more than one .cpp files.
I just overcame a similar error message, and lots more with the procedure below. Symptom: one linker error for every invocation of every function defined in a particular header, plus one at the end of output for every function defined in the header.
Then I remembered that when I had originally created this header, I accidentally had selected "add->new item->c++ file" and though I named it 'whatever.h', it seems Visual Studio considered them both the same kinds of files because of the incorrect action I used to add one. Examining the build output logs made this obvious.
SOLUTION (Using VS Community 2019)
Back up project first (just to be safe).
Right-click the offending header file and select "Exclude from project" (this will not delete them; the VS project will just ignore them).
Do same for the matching .c or .cpp file.
Do Build->Clean on project
Do Build->Rebuild on project
-- there of course will be errors---
Right-click Header Files->Add->Existing Item, then select the .h file
Right-click Source Files->Add->Existing Item, the select the .c or .cpp file
Do Build->Rebuild on project.
This completely cleaned it up for me, relieving me of many irritating linker errors including LNK4042 from the title of this question.
I resolved it changing filenames in my project. There was two files named main.c and main.cpp. I changed one of them and worked.
I'm a real beginner and I'm programming in C++ using Visual Studio.
I've a simple cpp code that recalls some functions written in a .c and .h file. I included that file by means of #include directive and the IDE "sees" the function.
When I compile, I get this
Error 7 error LNK2019: unresolved external symbol _IMUsendAccelToFIFO referenced in function _main D:\Cprojects\Pencil\Pencil\Pencil.obj Pencil
What am I missing here?
Thank you all!
It is a linker error, not a compiler error. The compiler is happy, it saw the declaration of function in the .h file. The linker isn't, it cannot find the definition of the function.
Add the .c file to your project.
If you get an error in Visual Studio you can actually google for the error code and you will get pretty extensive information for that. In this case, googling LNK2019 gives this MSDN page as first hit, which also provides some examples on how you get the error.
Your vendor should have provided some .lib files for you (usually found in a folder named lib?). Make sure that these are added in the project via:
Project > Properties > Configuration Properties > Linker > Input > Additional Dependencies
You could also see if there is any "get started" information for you from your vendor, which explains which dependencies you have to include in your project.
If you feel unsure of what a compiler and what a linker does, pick up a book that explains it, or browse some free alternatives.
Are you using ghettopilot? that's the only reference I can find on the web to the function you're missing. If you are, then you need to include the .lib file for that library in your link options.
Visual Studio will compile .c files as C and .cpp files as C++ by default, and this can cause trouble because if you want to call functions defined in a .c file from a .cpp file, then you must wrap the header in extern "C" { }, as the compiler will expect all functions not declared extern "C" to be from C++. This is because of an implementation detail called name mangling. Alternatively, you could force all files to be compiled as C or as C++ in the project settings.
Solved! Thank you very much!
The libraries I was using needed to be built. I tried but I couldn't build them as I used to get "heap space" error!
I installed Visual Studio 2005 (with which the code was produced by the vendor) and it worked at first attempt! There are probably some back-compatibility issues..
I've just been beaten (rather hardly) on the head by some non-trivial warning from Visual Studio 2010 (C++).
The compilation gave the following output:
1 Debug\is.obj : warning LNK4042: object specified more than once; extras ignored
1 Debug\make.obj : warning LNK4042: object specified more than once; extras ignored
1 Debug\view.obj : warning LNK4042: object specified more than once; extras ignored
1 identity.obj : error LNK2019: unresolved external symbol void __cdecl
test::identity::view(void) (?view#identity#test##YAXXZ) referenced in function void __cdecl test::identity::identity(void) (?identity#0test##YAXXZ)
1 identity.obj : error LNK2019: unresolved external symbol void __cdecl test::identity::make(void) (?make#identity#test##YAXXZ) referenced in function void __cdecl test::identity::identity(void) (?identity#0test##YAXXZ)
1 range.obj : error LNK2019: unresolved external symbol void __cdecl test::range::is(void) (?is#range#test##YAXXZ) referenced in function void __cdecl test::range::range(void) (?range#0test##YAXXZ)
Linker errors are always a pain to debug... but there were unresolved references, and so I checked... but the source is well-formed... and finally it hit me:
My folder hierarchy looks like so:
src/
identity/
is.cpp
make.cpp
view.cpp
range/
is.cpp
make.cpp
view.cpp
and so does the hierarchy in the Solution (I always set it up so that it mimicks the "real" folder structure).
And the diagnostic outputs:
Debug\is.obj
Debug\make.obj
Debug\view.obj
Along with a warning which says that the .obj has been passed twice to the linker and that one will be ignored.
Search no more: Visual has neatly flatten my folder hierarchy, and therefore is unable to neatly compile the source.
At the moment, I am simply thinking of renaming the files, that should cover the issue...
... but is there a way to have Visual Studio NOT flatten the file hierarchy ?
I had a similar problem with linker warning LNK4042: object specified more than once; extras ignored. In my case Visual Studio was trying to compile both header and source files with the same name - MyClass.h and MyClass.cpp. It happened because I renamed .cpp file to .h and Visual Studio got confused. I noticed the problem by looking at the compiler logs in the Debug directory. To resolve just remove .h file from the project then add it again.
Just wanted to cross post what I believe to be the answer, if you open the properties for the entire project, and the change the value under C/C++ -> Output Files -> "Object File Name" to be the following:
$(IntDir)/%(RelativeDir)/
Under VS 2010, I believe this will disambiguate all of the object files (as I believe windows won't let you under any crazy circumstances have two files with the same names in the same directory). Please also check out the details here.
Right-click the .cpp file in the Solution Explorer window, Properties, C/C++, Output Files, Object File Name setting. The default is $(IntDir)\, that's what is doing the flattening. All the .obj file will go into $(IntDir), the "Debug" directory in the debug configuration.
You can change the setting, say $(IntDir)\is2.obj. Or select all the files from one group (use Shift+Click) and change the setting to, say, $(IntDir)\identity\
Or you can change the .cpp filename so that .obj files don't overwrite each other. Having files with the exact same name in two directories is a bit odd.
Or you can create multiple projects, creating, say, .lib projects for the files in identity and range. Commonly done in makefile projects for example. That does however make managing the compile and link settings more of a hassle unless you use project property sheets.
Right click on header file -> Property -> ItemType (select C/C++ Header). Do the same with Cpp file but select C/C++ Compiler (it's work for me)
Alternatively to deleting and making a new file you can change the compile/include settings.
Go to your project.vcxproj file, open it with an editor, find the html like line <ItemGroup>.
It should look something like:
<ItemGroup>
<ClCompile Include="implementation.cpp" />
</ItemGroup>
and
<ItemGroup>
<ClInclude Include="declaration.hpp" />
</ItemGroup>`
Assuming your implementation files are .cpp and your declarations are .hpp. Make sure your all your implementation files are listed between the first section if you have more then one and likewise for the second section for multiple declaration files.
I had this problem with stdafx.cpp. Somehow stdafx.cpp got duplicated, so there was a second StdAfx.cpp (mind the different case).
After I removed the StdAfx.cpp everything worked fine!
Using VS 2010.
I use $(IntDir)\%(Directory)\ under C/C++ -> Output Files -> "Object File Name".
I used to have in the same project .c and .cpp files with the same filenames. The files were in folders all over the place and the solutions provided by others created a mess, and folder hell (in my case). Even Release builds would overwrite Debug builds!
A good (not perfect) solution would be to use $(ParentName), but for some reason beyond anyone's grasp it has been removed from later versions of Visual Studio (2015+).
What I use succesfully now is:
$(IntDir)%(Filename)%(Extension).obj
which at least separates .c built object files from .cpp.
I'd like to point out one possible reason for why the ItemType of a .h file would change from C/C++ header to C/C++ compiler:
In the Solution Explorer window of VS (2019 here), right click the project name, choose Add -> New Item;
Select the C++ File (.cpp) template, but type something.h in the name input area, then click OK to add it;
Then you'll encounter the LNK4042 warning if the something.h file be included within more than one .cpp files.
I just overcame a similar error message, and lots more with the procedure below. Symptom: one linker error for every invocation of every function defined in a particular header, plus one at the end of output for every function defined in the header.
Then I remembered that when I had originally created this header, I accidentally had selected "add->new item->c++ file" and though I named it 'whatever.h', it seems Visual Studio considered them both the same kinds of files because of the incorrect action I used to add one. Examining the build output logs made this obvious.
SOLUTION (Using VS Community 2019)
Back up project first (just to be safe).
Right-click the offending header file and select "Exclude from project" (this will not delete them; the VS project will just ignore them).
Do same for the matching .c or .cpp file.
Do Build->Clean on project
Do Build->Rebuild on project
-- there of course will be errors---
Right-click Header Files->Add->Existing Item, then select the .h file
Right-click Source Files->Add->Existing Item, the select the .c or .cpp file
Do Build->Rebuild on project.
This completely cleaned it up for me, relieving me of many irritating linker errors including LNK4042 from the title of this question.
I resolved it changing filenames in my project. There was two files named main.c and main.cpp. I changed one of them and worked.
I'm using MSVC++ 6 to build a very large project. Some of the source files in this project are shared with a small utility that we use for maintaining the application. Previously, this small utility required linking against many libs from the main app and also required the main app's DLLs at runtime. I was tasked with removing these dependencies, which sounded pretty simple... unfortunately, the precompiled headers used in the main app are causing me a lot of trouble.
I first reworked all the files in the utility to explicitly include everything they need and then I removed the #include directives for the PCH (this removed 95% of the unnecessary dependencies for the utility). This works great for compiling the utility. Now, however, compiling the main app gives me errors about missing precompiled header directives. I thought "great, I'll just conditionally include the PCH". This does not seem to work... I get "unexpected #endif", as mentioned here. My next thought was to turn off PCH in the main app for the three source files that are shared between the utilty and the main app. This compiles successfully, but I get a bunch of errors that look like this during linking:
tls7d.lib(tls707d.dll) : error LNK2005: "public: unsigned int __thiscall RWCString::length(void)const " (?length#RWCString##QBEIXZ) already defined in stripledescypher.obj
AFAICT, all of the multiply defined symbols are ones that I explicitly include in the shared files to avoid the need for the PCH. My hunch is that since I'm linking those 3 files into the same DLL as the PCH .cpp file, they're compiled in multiple places. Is there any way out of this mess? I'll try just about anything...
When the compiler finds a definition of a symbol X when processing a compilation unit, it will create a hint for the linker: X is in here!
The compilation of two source files, both #includeing a header with a definition (i.e. not a mere declaration) will result in two object files defining the same symbol. The linker will find a symbol multiply defined.
So it appears that your stripledescypher object file includes a definition of the WCString::lenght()const method. This may be due to the function body being defined in the class' header or something the like.
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
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
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)
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.
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.
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.
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.
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
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.
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.
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.
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.
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
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.
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
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!!
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.
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.