From: Fenster on
In message <CRlA+xDbdNPFFwmF(a)FensterPC.croctec.co.uk>, Fenster
<fenster(a)croctec.co.uk> writes
>
>I have a Windows application that's started throwing out these linker
>errors (from Visual Studio 6):
>
>nafxcwd.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator
>new(unsigned int)" (??2(a)YAPAXI@Z) already defined in
>LIBCMTD.lib(new.obj)
>
>nafxcwd.lib(afxmem.obj) : error LNK2005: "void __cdecl operator
>delete(void *)" (??3(a)YAXPAX@Z) already defined in
>LIBCMTD.lib(dbgdel.obj)
>
>leap76test\debug/leap76test.exe : fatal error LNK1169: one or more
>multiply defined symbols found
>
>
>
>The application is multi-threaded and if I don't link with an external
>library (which I thought was where/why the conflict was arising) I
>still get the same errors (plus some additional unresolved externals
>obviously).
>
>If I link with "/force" (and the external library), as per the help for
>LNK1169 I get the following warnings:
>
>nafxcwd.lib(afxmem.obj) : warning LNK4006: "void * __cdecl operator
>new(unsigned int)" (??2(a)YAPAXI@Z) already defined in
>LIBCMTD.lib(new.obj); second definition ignored
>
>nafxcwd.lib(afxmem.obj) : warning LNK4006: "void __cdecl operator
>delete(void *)" (??3(a)YAXPAX@Z) already defined in
>LIBCMTD.lib(dbgdel.obj); second definition ignored
>
>leap76test\debug/leap76test.exe : warning LNK4088: image being
>generated due to /FORCE option; image may not run
>
>
>
>It doesn't seem a satisfactory solution to me and although the
>application seems to run okay I've got this niggling doubt in my mind
>that if Microsoft are suggesting that it might not run then there's a
>good chance that sooner or later, for no apparent reason, it'll stop
>running.
>
>The other oddity is that I can build the application on another PC
>without any warnings or errors. Could it be that Windows 2000 is
>patched/updated to different levels somewhere? Both VS installations
>are at SP6.
>
Apologies for this but that last statement is definitely not true. The
VC++ that does the build successfully is probably at SP4 (maybe even
SP3, I'm not sure how I can differentiate these).


>I'd appreciate any pointers to a more satisfactory solution (than
>"/force" or "use the other PC").
>
>Thanks.
>

--
Fenster
From: Fenster on
In message <#0b21hr9GHA.568(a)TK2MSFTNGP05.phx.gbl>, Norbert Unterberg
<nunterberg(a)newsgroups.nospam> writes
>
>Fenster wrote:
>
>> nafxcwd.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator
>>new(unsigned int)" (??2(a)YAPAXI@Z) already defined in
>>LIBCMTD.lib(new.obj)
>
>I was hit by this problem some time ago, and I searched this list for
>solutions. I found several mails where people had this problem but I
>never saw the solution.
>
>However, I think I know what is going on.
>This problem comes when all of the following conditions are true:
>
> * Your application uses MFC
> * You are using the static versions of the runtime/MFC libraries
> * You also link a third-party library that uses C++ without MFC
>
>This is what happens:
> * The linker tries to resolve the externals, and happens to start
>witht the external third-party library. It then resolves the new/delete
>operators by pulling in the standard runtime library LIBCMTD.
> * Then it goes on linking the application. It detects MFC and pulls in
>the MFC library nafxcwd. The problem: MFC also defines new/delete, and
>suddenly you have multiple definitions of these operators.
>
>The only workaround I have found to resolve this: Force the linker to
>import the MFC library first:
>Go into your project settins, linker tab, Category "General", and make
>sure that the "Object/Library modules" field contains
>
> "nafxcw.lib libcmt.lib" for the release build, and
> "nafxcwd.lib libcmtd.lib" for the debug build.
>
>Norbert


The solution rang a bell so I went back to the docs again and found
Q148652, if anyone's still reading this thread. It contains a more
generic solution (single-threaded, multi-threaded, unicode, DLLs, etc.)
although it may need some work for VC++ younger than V6.

--
Fenster