error LNK2005: new and delete already defined in CppUTest.lib(MemoryLeakWarningPlugin.obj)

[Alex Yang]

error LNK2005: new and delete already defined in CppUTest.lib(MemoryLeakWarningPlugin.obj)

I want to use CppUTest to create unit test for our project, but when I linked it, I got the following errors. 

1>uafxcwd.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator new(unsigned __int64,char const *,int)" (??2@YAPEAX_KPEBDH@Z) already defined in CppUTest.lib(MemoryLeakWarningPlugin.obj)

1>uafxcwd.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator new[](unsigned __int64,char const *,int)" (??_U@YAPEAX_KPEBDH@Z) already defined in CppUTest.lib(MemoryLeakWarningPlugin.obj)

1>uafxcwd.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator new(unsigned __int64)" (??2@YAPEAX_K@Z) already defined in CppUTest.lib(MemoryLeakWarningPlugin.obj)

1>uafxcwd.lib(afxmem.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPEAX@Z) already defined in CppUTest.lib(MemoryLeakWarningPlugin.obj)

1>uafxcwd.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator new[](unsigned __int64)" (??_U@YAPEAX_K@Z) already defined in CppUTest.lib(MemoryLeakWarningPlugin.obj)

1>uafxcwd.lib(afxmem.obj) : error LNK2005: "void __cdecl operator delete[](void *)" (??_V@YAXPEAX@Z) already defined in CppUTest.lib(MemoryLeakWarningPlugin.obj)

I searched google and stackoverflow, I find something http://support.microsoft.com/kb/148652 

I acted as what said in the link but I still got the similar errors. 

1>CppUTest.lib(MemoryLeakWarningPlugin.obj) : error LNK2005: "void * __cdecl operator new(unsigned __int64)" (??2@YAPEAX_K@Z) already defined in uafxcwd.lib(afxmem.obj)

1>CppUTest.lib(MemoryLeakWarningPlugin.obj) : error LNK2005: "void * __cdecl operator new(unsigned __int64,char const *,int)" (??2@YAPEAX_KPEBDH@Z) already defined in uafxcwd.lib(afxmem.obj)

1>CppUTest.lib(MemoryLeakWarningPlugin.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPEAX@Z) already defined in uafxcwd.lib(afxmem.obj)

1>CppUTest.lib(MemoryLeakWarningPlugin.obj) : error LNK2005: "void * __cdecl operator new[](unsigned __int64)" (??_U@YAPEAX_K@Z) already defined in uafxcwd.lib(afxmem.obj)

1>CppUTest.lib(MemoryLeakWarningPlugin.obj) : error LNK2005: "void * __cdecl operator new[](unsigned __int64,char const *,int)" (??_U@YAPEAX_KPEBDH@Z) already defined in uafxcwd.lib(afxmem.obj)

1>CppUTest.lib(MemoryLeakWarningPlugin.obj) : error LNK2005: "void __cdecl operator delete[](void *)" (??_V@YAXPEAX@Z) already defined in uafxcwd.lib(afxmem.obj)

Any comment on how to resolve this problem? 

[Bas Vodde]

Hi Alex,

Its been a while I've worked with Visual C++, so maybe someone else can answer more up-to-date. (which VS version?)

Anyways, the original errors seems 'right'. According to the MSDN documentation you send, the uafxcwd.lib should have defined operator new as "weak" linkage. AFAIK that means it will not give an error when it is already defined in another module. So, I'm a bit surprised it would give that error.

Not sure this helps you further, but perhaps something to try is to write a test program to overload operator new and link that to uaxfcwd.lib and see if you get the same error. It should, then you can try to resolve it in the small test project. If it doesn't, then there is indeed something wrong in linker order.

Bas

> --
> You received this message because you are subscribed to the Google Groups "cpputest" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cpputest+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Martin Ertsaas]

As Bas, I'm unsure about MS, but this could be wrong link order. My
guess is that CppUTest.lib should be linked after uafxcwd, according to
your error, it seems like it's the opposite.

At least on Linux you could get these kind of errors if you have the
wrong link order, and define one of them as "weak". I would start by
trying to mode the linking of CppUTest as the last linked in library.

- Martin

[Bas Vodde]

Hi Martin,

> As Bas, I'm unsure about MS, but this could be wrong link order. My
> guess is that CppUTest.lib should be linked after uafxcwd, according to
> your error, it seems like it's the opposite.

CppUTest.lib should be linked *before* the uafxcwd.lib.

But, I think this is exactly the problem :) I thought that the uafxcwd.lib is the Standard C library… but it is not, of course… it is the MFC library.

And the problem isn't that there is a conflict between StdC++ library and MFC (which is what the link described) but the problem is at a whole new level :) It is between MFC operator new overload and the CppUTest operator new overload!

I wonder how you can disable the operator new overload in MFC. Interesting, let me google a bit too.

Bas

[Bas Vodde]

Hi Alex,

Hrm… I think this is harder than I expected, especially without having a compiler (or linker in this case).

The problem seems to be that you are using MFC and that means there are now 3 operator news:
- operator new defined in CppUTest.lib
- operator new defined in MFC
- operator new defined in Standard C++

The last one (which the link you send was about) is not really a problem as it has "weak linkage". The first two do not and they are the ones that seem to conflict. There are a couple of potential ways around this.

- Do not use MFC :P
- Turn off the memory leak overload in CppUTest. It is controlled by: CPPUTEST_USE_MEM_LEAK_DETECTION. I'll need to know how you build CppuTest in order to say how to do it.
- Potential solution: Try to use MFC dynamic libraries. Not sure if this would work, but one article mentioned it.
- Look for the "force symbol" linker flag. At least gcc has such a flag, I'm not sure if VC has. I looked but couldn't find it.
- Other creative solution :)

Whatever you chose, please let us know how you fixed it. I think this actually deserves a mention in the manual.

Thanks,

Bas





On 22 Apr, 2013, at 4:09 PM, Alex Yang <yaya...@gmail.com> wrote:

[Alex Yang]

Thank you, thanks to all of you very much. 

1. My VS is VS 2010, and I use VS 2010 to build CppUTest lib 

2. I also want to not use MFC, but the target source file I want to test is legacy code which is using MFC. So, I can't remove this dependency.

3. I used VS 2010 to open the sln under C:\CppUTest-v3.3\CppUTest_VS2010.sln, and build all with parameters debug, and Multi-threaded Debug (/MTd) and x64. 

    so, if we can disable memory leak detection, it may help to decrease the complexity. 

4. what does "force symbol" means? VC may has different name. 

5. My test project is a new created project. not sure "creative solution". 

[Bas Vodde]

Hola Alex,

I'll keep the reply short as I'll be going home :)

> Thank you, thanks to all of you very much.
>
> 1. My VS is VS 2010, and I use VS 2010 to build CppUTest lib
> 2. I also want to not use MFC, but the target source file I want to test is legacy code which is using MFC. So, I can't remove this dependency.

Ok, I understand.

> 3. I used VS 2010 to open the sln under C:\CppUTest-v3.3\CppUTest_VS2010.sln, and build all with parameters debug, and Multi-threaded Debug (/MTd) and x64.

Ah ok, So not used CMake?

> so, if we can disable memory leak detection, it may help to decrease the complexity.

Yes, the easiest will be to add the CPPUTEST_MEM_LEAK_DETECTION_DISABLED define to your settings. That should disable the CppUTest memory leak checking completely and you got no more conflict (and no benefit of the memory leak checking)

> 4. what does "force symbol" means? VC may has different name.

"force symbol" would mean that you tell the linker to just take the first symbol it finds and not complain about duplicate symbols :) Its a bit an exotic linker flag, but useful at times (such as these)

> 5. My test project is a new created project. not sure "creative solution".

Eheh, I mean, another creative solution to this problem. I'm sure there must be another solution which we're not aware of yet….

Thanks,

Bas

[Alex Yang]

thanks a lot. 

On Monday, April 22, 2013 5:33:13 PM UTC+8, Bas Vodde wrote:

Hola Alex,

I'll keep the reply short as I'll be going home :)

> Thank you, thanks to all of you very much.
>
> 1. My VS is VS 2010, and I use VS 2010 to build CppUTest lib
> 2. I also want to not use MFC, but the target source file I want to test is legacy code which is using MFC. So, I can't remove this dependency.

Ok, I understand.

> 3. I used VS 2010 to open the sln under C:\CppUTest-v3.3\CppUTest_VS2010.sln, and build all with parameters debug, and Multi-threaded Debug (/MTd) and x64.

Ah ok, So not used CMake? [alex] : No, I don't use CMake, just using VS2010 build the sln directly. 

>     so, if we can disable memory leak detection, it may help to decrease the complexity.

Yes, the easiest will be to add the CPPUTEST_MEM_LEAK_DETECTION_DISABLED define to your settings. That should disable the CppUTest memory leak checking completely and you got no more conflict (and no benefit of the memory leak checking)

[alex]: YES. I added it to CppUTest project and build the CppUTest.lib and then link it in my test project, the link error is disappeared. 

em, it means that I can't leverage the memory leak detection function in CppUTest. At least, we can continue to next work. 

> 4. what does "force symbol" means? VC may has different name.

"force symbol" would mean that you tell the linker to just take the first symbol it finds and not complain about duplicate symbols :) Its a bit an exotic linker flag, but useful at times (such as these)

[alex]: I did it (attached the screen shot), but it can't solve the problem. 

[Bas Vodde]

Hola,

> Ah ok, So not used CMake? [alex] : No, I don't use CMake, just using VS2010 build the sln directly.

Oki.

> Yes, the easiest will be to add the CPPUTEST_MEM_LEAK_DETECTION_DISABLED define to your settings. That should disable the CppUTest memory leak checking completely and you got no more conflict (and no benefit of the memory leak checking)
>
> [alex]: YES. I added it to CppUTest project and build the CppUTest.lib and then link it in my test project, the link error is disappeared.

Good. Too bad you won't be able to get the per-test memory leak detection though :P There might be another solution to this too.

> > 4. what does "force symbol" means? VC may has different name.
>
> "force symbol" would mean that you tell the linker to just take the first symbol it finds and not complain about duplicate symbols :) Its a bit an exotic linker flag, but useful at times (such as these)
> [alex]: I did it (attached the screen shot), but it can't solve the problem.

Ok, that seems to be somehting different. This seems to force a linker symbol even if it isn't used. Thats not the case as in this case you got 2 linkers symbols that are used and in conflict and you'd need to 'force' one of those…

So, the "force" in this case has a different meaning.

Bas

> <Image_4.jpg>

[Fran Hao]

try this 

http://www.cnblogs.com/qingtian224/p/5833456.html

在 2013年4月22日星期一 UTC+8下午4:09:37，Gamer Ya写道：

[Fran Hao]

Thank you for your answer to solve my problem.
I through CPPUTEST_USE_MEM_LEAK_DETECTION I solved the problem of compilation.
But I want to know what should I do if I want to do memory leak detection.
Looking forward to your answer

在 2013年4月22日星期一 UTC+8下午4:50:16，Bas Vodde写道：