Trying to build Qt 5.6 from source on Windows 7 using MSVC13. Compilation goes fine, but I get two linker errors regarding multiply defined symbols:
Qt5SerialBus.lib(qmodbusdevice.obj) : error LNK2005: "class QLoggingCategory const & __cdecl QT_MODBUS(void)" (?QT_MODBUS##YAAEBVQLoggingCategory##XZ) already defined in mainwindow.obj
Qt5SerialBus.lib(qmodbusdevice.obj) : error LNK2005: "class QLoggingCategory const & __cdecl QT_MODBUS_LOW(void)" (?QT_MODBUS_LOW##YAAEBVQLoggingCategory##XZ) already defined in mainwindow.obj
release\adueditor.exe : fatal error LNK1169: one or more multiply defined symbols found
I suspect the problem (and solution) are similar to this one in which the offending functions can just be marked inline, however I can't find the definitions for these two functions anywhere in the modbus code. Does anyone know where "QT_MODBUS" and "QT_MODBUS_LOW" are defined, or is there another workaround to this?
Related
I'm been trying for the last couple of hours to solve an error that I can't get rid of. Here it is the gist: https://gist.github.com/pluralism/11294490
I'm out of ideas because everything looks correct for me. The compilation error I'm getting is the following:
1>MenuCAL.obj : error LNK2005: "void __cdecl printSquareArray(int * *,unsigned int)" (?printSquareArray##YAXPAPAHI#Z) already defined in calproject.obj
1>C:\Users\Andre Pinheiro\Desktop\calproject\Debug\calproject.exe : fatal error LNK1169: one or more multiply defined symbols found
If you need other files please feel free to ask. Thanks in advance!
If you want to define printSquareArray in a header, mark it inline to allow a definition in every translation unit that includes the header.
Alternatively, move the definition into a source file, so it's only defined once.
I have inherited a C++ solution with 3 projects, one compiling to a .DLL, the other two to .EXEs . The DLL builds on its own fine, but the other two, when built, produce around 65 LNK2005 errors, the majority of which are referencing the same .obj file, as shown in the log exert below:
Linking...
Function.obj : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/OPT:ICF' specification
Function.obj : error LNK2005: _ReadLocalRegister already defined in Function.obj
Function.obj : error LNK2005: _getSource already defined in Function.obj
Function.obj : error LNK2005: _SendLogEvent already defined in Function.obj
Function.obj : error LNK2005: _DebugMsg already defined in Function.obj
Function.obj : error LNK2005: _MyInformationMsg already defined in Function.obj
MyNTService.obj : error LNK2005: "public: __thiscall CMyNTService::CMyNTService(void)" (??0CMyNTService##QAE#XZ) already defined in MyNTService.obj
MyNTService.obj : error LNK2005: "public: virtual void __thiscall CMyNTService::OnStop(void)" (?OnStop#CMyNTService##UAEXXZ) already defined in MyNTService.obj
MyNTService.obj : error LNK2005: "public: void __thiscall CMyNTService::SaveStatus(void)" (?SaveStatus#CMyNTService##QAEXXZ) already defined in MyNTService.obj
....and so it goes on!
I am a C# coder, only basic C++ knowledge, so I am lost with this. The solution is an 15 year old C solution I am attempting to rebuild as a C++ solution in VS2008. I have managed to build it once, nothing has changed, but perhaps some config settings have changed since then.
Does anyone have ideas where I could start to look...?
Many thanks!
It sounds like you're missing inclusion guards on the header file for that object.
Add:
#ifndef SomeUniqueName
#define SomeUniqueName
//Code goes here.
#endif
Wrapping the code in the header file. The compiler will go through that header file many times when processing your code as it's included in many places (most likely). The inclusion guards stop redefinition of things that have already been defined on previous passes.
PS: It also might help to do a "make clean". Makefiles can be finnicky especially if not made 100% right and sometimes when dependencies are off you need to clean before rebuilding.
in msvc110 (2012), I encountered the same error and the only workaround i found was to create a class and a separate DLL for the recurrent functions I used in the different files.
Here's the link to do so.
Cheers
It has been about a year since I wrote any .dll plugins that use LibCurl, but I decided to start on another one tonight. Unfortunately, I have been combating the same linker errors for almost 4 hours now, and I am completely lost.
I am statically building LibCurl, and it appears to be fine for the most part, except I am getting the following linker errors.
1>MSVCRT.lib(MSVCR90.dll) : error LNK2005: _calloc already defined in memoverride.obj
1>MSVCRT.lib(MSVCR90.dll) : error LNK2005: _realloc already defined in memoverride.obj
1>MSVCRT.lib(MSVCR90.dll) : error LNK2005: _free already defined in memoverride.obj
1>MSVCRT.lib(MSVCR90.dll) : error LNK2005: _malloc already defined in memoverride.obj
1>MSVCRT.lib(MSVCR90.dll) : error LNK2005: __strdup already defined in memoverride.obj
1>MSVCRT.lib(MSVCR90.dll) : error LNK2005: __malloc_crt already defined in memoverride.obj
I have tried...
1) Reorganizing my included libs due to MSDN saying LNK2005 was caused by this.
2) Rebuilding the LibCurl lib through MSVC Application, then through the Command-Line tool.
3) Excluding the libs that are causing issues.
and a bunch of other things that I cannot even remember now. Can anyone help me out with some information as to how I can solve these?
Problem was my .dll was /MT while the libcurl was /MD. Also, I had initially blocked "libcmt", so when I was switching libcurl to /MT, it was spewing errors.
So I have a Visual Studio 2010 project that uses external libraries and in order to get it compile without LNK2005 I had to juggle arround with the order of the libraries in the linker settings.
I got it to compile fine in release mode, but for whatever reasons I don't manage to get it to compile without LNK errors in debug.
Is there no way to generally ignore LNK2005 and tell the linker to simply use whatever he encounters first?
Thanks!
//edit: here are some of the errors output of the PARTICULAR problem. however I already tried to solve that in different ways with each solution giving me different linker problems. hence i'm looking for general solution to ignore LNK2005
Error 7 error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info##AAE#ABV0##Z) already defined in Libcmtd.lib(typinfo.obj)
...\msvcprtd.lib(MSVCP100D.dll)
Error 8 error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info##AAEAAV0#ABV0##Z) already defined in Libcmtd.lib(typinfo.obj)
...\msvcprtd.lib(MSVCP100D.dll)
Error 9 error LNK2005: _exit already defined in Libcmtd.lib(crt0dat.obj)
...\msvcprtd.lib(MSVCP100D.dll)
Error 10 error LNK2005: __invalid_parameter already defined in Libcmtd.lib(invarg.obj)
...\msvcprtd.lib(MSVCP100D.dll)
...
Error 37 error LNK1169: one or more multiply defined symbols found
You may try the linker-option /FORCE (Force File Output in the Linker General tab of the Project Properties). This will force the linker to create a exe/dll even when such errors occur. But its left to you to find out if this exe does work at all or even correctly. After all i would not recommend this strategy.
Linker errors can sometimes be tedious to solve, but usually it has to be done only after migrating or setting up a project. This may take quite a while - it sometimes took me more then a day, but it should be done properly.
You absolutely must not ignore linker errors, ever! A linker is telling you that it's confused about a symbol that's defined in multiple places - where should it take the definition from? Do you really want it to be arbitrary? What about when you change your code and the linker randomly decides to take the other definition which might suddenly break your code?
Instead of fighting the tool, correct your code so that it compiles and links without errors. This MSDN article has some information on fixing it, along with links for more information.
I have a Visual Studio 6 workspace I'm trying to convert to a Visual Studio 2008 solution. The output of said solution is a .dll. It has to be a .dll and it needs to statically link MFC as I can't redistribute MFC to existing customers.
The solution consists of three projects, say A, B, C. C is the Active Project, outputs the .dll and depends on B. B outputs a .lib and depends on A. A outputs a .lib.
In the General configuration properties I have A and B set to Static Library (.lib) and C set to Dynamic Library (.dll). All three projects are set to "Use MFC in a Static Library." Also, all three projects are set to "Multi-threaded" for Runtime Library and none of them have _AFXDLL defined.
Everything builds correctly up until the final linking stage where I see this:
1>nafxcw.lib(wincore.obj) : error LNK2005: _IsPlatformNT already defined in A.lib(Globals.obj)
1>nafxcw.lib(wincore.obj) : error LNK2005: _InitMultipleMonitorStubs already defined in A.lib(Globals.obj)
1>nafxcw.lib(wincore.obj) : error LNK2005: _xGetSystemMetrics#4 already defined in A.lib(Globals.obj)
1>nafxcw.lib(wincore.obj) : error LNK2005: _xMonitorFromPoint#12 already defined in A.lib(Globals.obj)
1>nafxcw.lib(wincore.obj) : error LNK2005: _xMonitorFromRect#8 already defined in A.lib(Globals.obj)
1>nafxcw.lib(wincore.obj) : error LNK2005: _xMonitorFromWindow#8 already defined in A.lib(Globals.obj)
1>nafxcw.lib(wincore.obj) : error LNK2005: _xGetMonitorInfo#8 already defined in A.lib(Globals.obj)
1>nafxcw.lib(wincore.obj) : error LNK2005: _xEnumDisplayMonitors#16 already defined in A.lib(Globals.obj)
1>nafxcw.lib(wincore.obj) : error LNK2005: _xEnumDisplayDevices#16 already defined in A.lib(Globals.obj)
1>nafxcw.lib(wincore.obj) : error LNK2005: _g_pfnGetSystemMetrics already defined in A.lib(Globals.obj)
1>nafxcw.lib(wincore.obj) : error LNK2005: _g_pfnMonitorFromWindow already defined in A.lib(Globals.obj)
1>nafxcw.lib(wincore.obj) : error LNK2005: _g_pfnMonitorFromRect already defined in A.lib(Globals.obj)
1>nafxcw.lib(wincore.obj) : error LNK2005: _g_pfnMonitorFromPoint already defined in A.lib(Globals.obj)
1>nafxcw.lib(wincore.obj) : error LNK2005: _g_pfnGetMonitorInfo already defined in A.lib(Globals.obj)
1>nafxcw.lib(wincore.obj) : error LNK2005: _g_pfnEnumDisplayMonitors already defined in A.lib(Globals.obj)
1>nafxcw.lib(wincore.obj) : error LNK2005: _g_pfnEnumDisplayDevices already defined in A.lib(Globals.obj)
1>nafxcw.lib(wincore.obj) : error LNK2005: _g_fMultiMonInitDone already defined in A.lib(Globals.obj)
1>nafxcw.lib(wincore.obj) : error LNK2005: _g_fMultimonPlatformNT already defined in A.lib(Globals.obj)
1>nafxcw.lib(viewprnt.obj) : error LNK2005: "public: virtual int __thiscall CPrintingDialog::OnInitDialog(void)" (?OnInitDialog#CPrintingDialog##UAEHXZ) already defined in B.lib(ImagePropertiesDlg.obj)
1>nafxcw.lib(viewprnt.obj) : error LNK2005: "public: __thiscall CPrintingDialog::CPrintingDialog(class CWnd *)" (??0CPrintingDialog##QAE#PAVCWnd###Z) already defined in B.lib(ImagePropertiesDlg.obj)
1>nafxcw.lib(viewprnt.obj) : error LNK2005: "public: virtual void __thiscall CPrintingDialog::OnCancel(void)" (?OnCancel#CPrintingDialog##UAEXXZ) already defined in B.lib(ImagePropertiesDlg.obj)
I've Googled the problem to death and seen other people with a similarish issue, but can't seem to solve it. I tried adding nafxcw.lib to the Ignored libraries for C, but that turned this batch of linker errors into 1500+ unresolved symbol errors. I can get it to compile/link if I make it dynamically link MFC, but like I said, I need it to statically link. I feel like I'm missing something rather simple but can't seem to wrap my head around it. Any and all random thoughts and ideas will be greatly appreciated.
As is often the case, the solution turned out to be so mundane and obvious, I'm still kicking myself for banging my head on it for so long.
Basically, project A referenced above was not a project I directly pulled from the old VS6 workspace, but rather a project that had previously been converted by another team for use in another application. I assumed it was functionally equivalent to the original one, but that is very much not the case. These linking errors are actual, valid multiply defined linking errors. When I started digging in, I found that the first batch of errors was from including multimon.h in project A (something I don't even need, just removed it) and the second batch is from a class that is actually defined in both A and B.
Like I said, I'm still groaning over here, but at least I should be able to fix my problem now. Thanks for the help and always remember to NEVER assume ANYTHING.
When you tried ignoring the nafxcw library, did you add it back in to try to force a link order as suggested by this KB article? While your problem isn't an exact fit it may be related. Perhaps things could be resolved by monkeying with the link order.