1. error LNK2005: "public: __thiscall CString::operator char const *(void)const " (??BCString@@QBEPBDXZ) already defined in Markup.obj
几种解决方案:
a, 你只需要在工程设置里面,把
WIN32,NDEBUG,_WINDOWS,_MBCS,_USRDLL,MSGBOX_EXPORTS,_WINDLL,_AFXDLL
中的_USRDLL,删除,就可以正确编译了
b,http://support.microsoft.com/default.aspx?scid=kb;en-us;q148652
RESOLUTION There are two ways to resolve this problem. The first solution involves forcing the linker to link the libraries in the correct order. The second solution allows you to find the module that is causing the problem and to correct it.
Note The following steps are based on Visual C++ 6.0. Back to the top
Solution One: Force Linker to Link Libraries in Correct Order 1. On the Project menu, click Settings. 2. In the Settings For view of the Project Settings dialog box, click to select the project configuration that is getting the link errors. 3. On the Link tab, click to select Input in the Category combo box. 4. In the Ignore libraries box, insert the library names (for example, Nafxcwd.lib;Libcmtd.lib).
Note The linker command-line equivalent in /NOD:<library name>. 5. In the Object/library modules box, insert the library names. You must make sure that these are listed in order and as the first two libraries in the line (for example, Nafxcwd.lib Libcmtd.lib). To set this option in Visual C++ .NET, read the "Setting Visual C++ Project Properties" online help topic. Back to the top
Solution Two: Locate and Correct the Problem Module To view the current library link order, follow these steps: 1. On the Project menu, click Settings. 2. In the Settings For view of the Project Settings dialog box, click to select the project configuration that is getting the link errors. 3. On the Link tab, type /verbose:lib in the Project Options box. 4. Rebuild your project. The libraries will be listed in the output window during the linking process.
c, http://blog.edu.cn/user3/RFox/archives/2008/2140436.shtml
I want to add some initial code in DllMain in a MFC dll project, but after I added the code and compiled, there was a link error:
mfcs42d.lib(dllmodul.obj) : error LNK2005: _DllMain@12 already defined in DLLMAIN.OBJ
DLLMAIN.cpp is the file I created by my own and I define DllMain() in it.
What’s the reason? the linker complains that I have a DllMain in DLLMAIN.cpp but there’s another DllMain in mfcs42d.lib.
So how to use my own DllMain if a MFC dll project? There’s a quick answer on codeguru , but that article just show the tip without explaining it with more details.
The article says, just copy MFC’s dllmodule.cpp into your own project and compile, it will be OK. It seems to be nonsense but after I tried I found it works. But why? By commenting out unnecessary lines, I find these lines are the key point: //(dllmodule.cpp)
// The following symbol used to force inclusion of this module for _USRDLL #ifdef _X86_ extern “C” { int _afxForceUSRDLL; } #else extern “C” { int __afxForceUSRDLL; } #endif
Do you noticed the comment? it forces the inclusion of the module of dllmodule.obj. But how? A searching for _afxForceUSRDLL in MFC source code gives me the answer: //afx.h
// force inclusion of DLLMODUL.OBJ for _USRDLL #ifdef _USRDLL #pragma comment(linker, “/include:__afxForceUSRDLL”) #endif
Again the MFC designer gives us a good comment: “force inclusion of DLLMODUL.OBJ”, OK, got it.
Now let summary it up: 1)When you try to use MFC library, you surely will include afx.h directly or indirectly 2)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 my program, for __afxForceUSRDLL is defined in dllmodule.cpp That’s the common scenario.
Then you want to use your own DllMain in a mfc dll project, linker complains that there are two DllMain, one in your code, one in Dllmodule.obj.
The solution? Tell the linker to add my dllmain.obj for __afxForceUSRDLL. So we 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.
So the solution is just to add extern “C” { int _afxForceUSRDLL; } in the file where your own DllMain is defined, copying mfc’s dllmodule.cpp is not necessary :-)