LK2005 and LK1169 errors
Fenster
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@YAPAXI@Z) already defined in
LIBCMTD.lib(new.obj)
nafxcwd.lib(afxmem.obj) : error LNK2005: "void __cdecl operator
delete(void *)" (??3@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@YAPAXI@Z) already defined in
LIBCMTD.lib(new.obj); second definition ignored
nafxcwd.lib(afxmem.obj) : warning LNK4006: "void __cdecl operator
delete(void *)" (??3@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.
I'd appreciate any pointers to a more satisfactory solution (than
"/force" or "use the other PC").
Thanks.
--
Fenster
Norbert Unterberg
Fenster wrote:
> nafxcwd.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator
> new(unsigned int)" (??2@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
Bogdan
version of the external lib? Have you tried to build a release (i.e.
non-debug) version of your app?
If you are absolutely sure that you are getting the same link errors while
building without the external library then first try to clean and re-build
your project. If that does not work then copy-and-paste your full compiler
and linker command lines (as seen in build options) and post it to this
group.
"Fenster" <fen...@croctec.co.uk> wrote in message
news:CRlA+xDb...@FensterPC.croctec.co.uk...
Fenster
<nob...@nospam.com> writes
>Your are building a multithreaded debug app (note MTD). Do you have a debug
>version of the external lib?
Yes, the library is correct (i.e. separate release / debug versions).
I've also rebuilt these with the same VC++ environment as used for the
application but without success.
>Have you tried to build a release (i.e.
>non-debug) version of your app?
>
Tried that too, no difference.
The errors for a complete debug build are:
nafxcwd.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator
new(unsigned int)" (??2@YAPAXI@Z) already defined in
LIBCMTD.lib(new.obj)
nafxcwd.lib(afxmem.obj) : error LNK2005: "void __cdecl operator
delete(void *)" (??3@YAXPAX@Z) already defined in
LIBCMTD.lib(dbgdel.obj)
leap76test\debug/leap76test.exe : fatal error LNK1169: one or more
multiply defined symbols found
Error executing link.exe.
Creating browse info file...
leap76test.exe - 3 error(s), 0 warning(s)
For a complete release build the errors are:
nafxcw.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator
new(unsigned int)" (??2@YAPAXI@Z) already defined in LIBCMT.lib(new.obj)
nafxcw.lib(afxmem.obj) : error LNK2005: "void __cdecl operator
delete(void *)" (??3@YAXPAX@Z) already defined in LIBCMT.lib(delete.obj)
leap76test\release/leap76test.exe : fatal error LNK1169: one or more
multiply defined symbols found
Error executing link.exe.
Creating browse info file...
leap76test.exe - 3 error(s), 0 warning(s)
>If you are absolutely sure that you are getting the same link errors while
>building without the external library then first try to clean and re-build
>your project.
A complete build without the external library results in these errors:
nafxcwd.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator
new(unsigned int)" (??2@YAPAXI@Z) already defined in
LIBCMTD.lib(new.obj)
nafxcwd.lib(afxmem.obj) : error LNK2005: "void __cdecl operator
delete(void *)" (??3@YAXPAX@Z) already defined in
LIBCMTD.lib(dbgdel.obj)
CommsPort.obj : error LNK2001: unresolved external symbol
@PortOpenMSWin32@20
leap76test\debug/leap76test.exe : fatal error LNK1120: 1 unresolved
externals
Error executing link.exe.
Creating browse info file...
leap76test.exe - 4 error(s), 0 warning(s)
>If that does not work then copy-and-paste your full compiler
>and linker command lines (as seen in build options) and post it to this
>group.
For the debug build I have the following command lines:
/nologo /MTd /W4 /Gm /GX /ZI /Od /D "_DEBUG" /D "WIN32" /D "_WINDOWS"
/D "_MBCS" /D "_CPLUSPLUS" /D "_BUILD_LEAP76TEST"
/D "OTO_BREDA_76MM_HE_MOD_79" /FR"leap76test\debug/"
/Fp"leap76test\debug/leap76test.pch" /YX /Fo"leap76test\debug/"
/Fd"leap76test\debug/" /FD /GZ /c
and
gclfw.lib /nologo /subsystem:windows /incremental:yes
/pdb:"leap76test\debug/leap76test.pdb" /debug /machine:I386
/out:"leap76test\debug/leap76test.exe" /pdbtype:sept
/libpath:"..\libs\gcl520\lib"
or
gclfw.lib /nologo /subsystem:windows /incremental:yes
/pdb:"leap76test\debug/leap76test.pdb" /debug /machine:I386 /force
/out:"leap76test\debug/leap76test.exe" /pdbtype:sept
/libpath:"..\libs\gcl520\lib"
when using /force.
--
Fenster
Fenster
<nunte...@newsgroups.nospam> writes
>
>Fenster wrote:
>
>> nafxcwd.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator
>>new(unsigned int)" (??2@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.
>
external library from the build I still get the same errors (plus some
others obviously).
>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.
>
This worked a treat, thanks a lot. Yet another VC++ workaround to file
away for next time.
>Norbert
--
Fenster
Fenster
<fen...@croctec.co.uk> writes
VC++ that does the build successfully is probably at SP4 (maybe even
SP3, I'm not sure how I can differentiate these).
Fenster
<nunte...@newsgroups.nospam> writes
>
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