Errors Moc'ing, DEBUG information translating to RELEASE, _ITERATOR_DEBUG_LEVEL error

Hello everyone - newbie to QT, 25 years experience as software engineer (assembly, Modula-II, VB, C, C++, etc)(From Databases, Video, Music Software, etc). So feel free to get as technical as you wish with your response.

The problem here is my unfamiliarity with QT framework with Visual Studio. Attempts to debug an EXISTING QT project leads me here. In RELEASE mode, the program builds correctly no problem (Both in VS and Creator). When switching to DEBUG mode I receive a list of 3 errors (repeated);

Code:

---

8 lines->"warning LNK4042: object specified more than once; extras ignored"
 
50+ lines of this type error->"moc_abstractextractor.obj : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in abstractextractor.obj"
 
50+ lines of this type error->"moc_abstractextractor.obj : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MDd_DynamicDebug' doesn't match value 'MD_DynamicRelease' in abstractextractor.obj"

---

Of course I've already searched several forums for answers. NO there are NOT separate projects. All in one PROJECT. QObject is specified regarding the LNK4052 warning (which as a programmer - I'm not to worried about that yet - error resolution is more important). And many other solutions tried...

What seems to be occurring is "moc_<names>" (e.g. moc-abstractextractor.obj) converts to "<names>" (e.g. abstractextractor.obj) does not get compiled with debugging information. I noticed the modification times are very different - (so they compiler is not just making a copy) - using a hex editor - Debug information is in the moc_ OBJ Files, but not the in "normal names" OBJ files.

I've been in vcproj but didn't see anything unusual (Although this was late at night searching for what is getting thrown out). My next solution is time consuming restructuring of the project (deleting these particular moc files out of the project - renaming - reinserting them and deal with the fixing the errors the show up - which defeated the purpose of QT - because if I do that it all gets reconstructed to strict Visual).

I really hope someone has seen this before and have a good solution. I appreciate any help you might have to offer.

Quote:

---

he program builds correctly no problem (Both in VS and Creator).

---

Creator is only an IDE, it can use both the MS compiler and MinGW (the available out of the box Qt builds).
Which compiler is used is defined by the Kit you are using.
If you Kit uses the MSVC build chain, there is no difference between the two builds aside them being run in different IDE.

Quote:

---

My next solution is time consuming restructuring of the project (deleting these particular moc files out of the project

---

This is a hint for me that you are doing something pricipally wrong.
You usually should not be dealing with moc files in respect to the project.
The only thing you need to have in place is a build rule that scans your headers and generates the mocs before the actual build starts.
This includes adding the generate moc files to the project.
Did you install the qt plugin for MSVC? - it makes dealing with moc much easier under MSVC.

In general this sounds more like project configuration problem than anything specific to the code or Qt otherwise the release build would not build as well.
Make sure your debug configuration links against the Qt debug libs.
Make sure your mocs are generated and that your project knows where to find them.
Rebuild sometime helps too.

Good luck!

Reading these errors, it sounds to me like you are linking your debug mode build against the release mode Qt libraries. Note that Qt's debug libraries all have a "d" suffix on the library name (eq. Qt5Cored.lib/dll vs. Qt5Core.lib/dll in release mode). Be sure you're linking with the correct import libs in your Properties -> Linker -> Input -> Additional Dependencies setting.

If the linking is correct, check to see that the preprocessor isn't compiling with /D_ITERATOR_DEBUG_LEVEL=2. If it is, either remove this from the command line or change the constant to 0 for the release build.

All of the moc stuff is likely a red herring. You likely -will- get warnings of the type:

Code:

---

warning MSB8027: Two or more files with the name of moc_Foo.cpp will produce outputs to the same location. This can lead to an incorrect build result.  The files involved are GeneratedFiles\Debug\moc_Foo.cpp, GeneratedFiles\Release\moc_Foo.cpp.

---

This appears to be a bug in the way the Qt Visual Studio plugin has defined target rules for MOC and can be ignored. I've looked into it, but the rules definitions are so convoluted it isn't worth the effort to try to sort it.

Quote:

---

My next solution is time consuming restructuring of the project (deleting these particular moc files out of the project - renaming - reinserting them and deal with the fixing the errors the show up

---

No, no, no. The "moc_Foo.cpp" files are automatically generated by the MOC compiler, which reads the header files for those classes derived frm QObject (which includes QWidget and descendents). Deleting, renaming, etc. is useless and will make your situation even worse because now you'll have a mix of automatically generated and manually modified files.

Simply delete the "GeneratedFiles/Debug" directory and do a clean rebuild. My guess is somehow your timestamps got screwed up (or maybe someone inappropriately checked these files into your source control system).

If the files -are- in your source control system, get rid of the entire GeneratedFiles directory in source control. This is in the same category of error as checking in .obj files from the Release and Debug intermediate directories.

d_stranz - Thanks for responding... I'm just letting you know - I have your message... give me just a second... I think we found this very strange problem... Compiling now... I will. Sorry about the #icon to insert the tags... usually on forums I'm answering questions... LOL! give me 4 minutes... its recompiling.

---

Added after 28 minutes:

OKAY d_strange

AGAIN... thanks for your response. As I mentioned earlier I looked in the vcxproj file to see if there was any inconsistencies. I made note that this happen late at night like 11:30 to 1:00am. LOL. because of that - I looked again at that file that was generated from the QT plug-in for Visual Studio. This is what I Found;

Code:

---

<CustomBuild Include="DEBUG\.obj\abstractextractor.obj">
      <FileType>Document</FileType>
      <ExcludedFromBuild Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">true</ExcludedFromBuild>
      <AdditionalInputs Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">sfark\abstractextractor.cpp;%(AdditionalInputs)</AdditionalInputs>
      <Command Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">cl -D__LITTLE_ENDIAN__ -MD -arch:IA32 -D_CRT_SECURE_NO_WARNINGS -I. -Ilib -Ilib\win -Ilib\ogg_vorbis -Ilib\rtmidi -Ilib\stk -Ilib\qcustomplot -Igui_divers -Iconfiguration -Ipages -Iqcustomplot -Iressources -Isf2_core -Itools -Iclavier -Isynthetiseur -Isynthetiseur\elements -Isfark -Ilib\sf3 -I. -Ilib\sfarklib -I$(QTDIR)\include -I$(QTDIR)\include\QtPrintSupport -I$(QTDIR)\include\QtSvg -I$(QTDIR)\include\QtWidgets -I$(QTDIR)\include\QtGui -I$(QTDIR)\include\QtANGLE -I$(QTDIR)\include\QtCore -IDEBUG\.moc -IDEBUG\.ui -I$(QTDIR)\mkspecs\win32-msvc2015 -c sfark\abstractextractor.cpp -FoDEBUG\.obj\abstractextractor.obj</Command>
      <Message Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">cl</Message>
      <Outputs Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">DEBUG\.obj\abstractextractor.obj;%(Outputs)</Outputs>
    </CustomBuild>

---

The -MD switch never converted to -MDd as it should. Once I changed it, the program was built. Still with warnings;

Code:

---

warning MSB8017: A circular dependency has been detected while executing custom build commands for item "DEBUG\.obj\abstractextractor.obj".

---

AND

Code:

---

DEBUG\.obj\abstractextractor.obj : warning LNK4042: object specified more than once; extras ignored

---

8 each. Which leads me to believe these are related to the first 8 warnings I received/mentioned on my original post.

SO APPRENTLY - The conversion between the loading the .pro in both (Creator and Studio) did not make this adjustment. O-WISE-ONE... do you have any idea why there is a "circular dependency". issue? I thought this was resolved with the CObject definition.

FINALLY

Don't worry about Restructuring part... my amateur days are long over.

Quote:

---

Originally Posted by d_stranz

No, no, no. The "moc_Foo.cpp" files are automatically generated by the MOC compiler, which reads the header files for those classes derived frm QObject (which includes QWidget and descendents). Deleting, renaming, etc. is useless and will make your situation even worse because now you'll have a mix of automatically generated and manually modified files.

---

I already isolated the ones generated by QT and the moc_<files> created by this original coder. LOL LOL LOL. I was only considering his - because it was the ones with the issue. I still have no idea why he did this. And it is these same 8 files.

THANK YOU SIR - put this one in your list of resolutions... sometimes on larger projects they may need to open the project file check the -MD switch.

Quote:

---

I was only considering his - because it was the ones with the issue. I still have no idea why he did this. And it is these same 8 files.

---

I have had Qt projects get all screwed up in VS for no apparent reason, possibly due to upgrades from one VS version to the next or one Qt version to the next and have had moc files get "stuck". It usually takes a careful hand-editing of the vc(x)proj file to fix things. A lot of the "stuckness" results from moc files generated for one build configuration (eg. debug) either getting unmarked as included in the build, or inappropriately marked as being in the other mode's build. In the first case, you will get stale moc_.cpp files that no longer match the file header, don't get deleted on a clean, but get compiled in anyway because they are "#include"-d from some other file. In the second case, you'll get files generated with debug information included in release build or vice versa.

The alternative if things are really messed up is to simply restart the project from scratch and add all of the existing .cpp, .h, .ui, and .qrc files back in and let the VS plugin macros figure out how to write the project files.

Not sure why you are seeing the circular dependency warning, but an "obj" shouldn't even appear as a target in a CustomBuild block. These should be only .cpp, .h, .ui, and .qrc files.

- All of the .h files for QObject-based classes should be in one or more ItemGroup, with a separate CustomBuild block for each .h that runs the MOC compiler.
- All of the .ui files for QWidget-based classes should be in one or more ItemGroup, with a separate CustomBuild block for each .ui that runs the UIC tool
- The .qrc file should be in an ItemGroup with a CustomBuild that runs the RCC resource compiler

There could be more than one ItemGroup for the first two categories; it might depend on the order in which new files are added to the project. There will be Condition attributes covering each build configurations for the CustomBuild steps.

I look at cases like this as Nature's way of demonstrating that experienced software developers still have the chops to fix the problems introduced by software bugs and other less experienced developers.

d_Stranz

Got you on the CustomBuild Block - A little bit later I'm going to look thru the vcxproj again (I don't want it to bite me in the butt later).

I just printed your response... hopefully it will narrow my search for this warning. You know the break down with QT more than me. Trusting your instincts.

Now that the program is running in debug mode - we can see whats been happening. One of the younger programmers still couldn't understand how I found all 8 of the -MD directives in the heap of mess in vc(x)proj file. APPARENTLY you are well aware of that mess - LOL LOL LOL. I just been doing this to long... and it helps when you are working at home on the crazy stuff.

I popped you in with another thanks - also put in as a friend. YOU SIR - Have a WONDERFUL day. If I discover these warnings within the next hour or so - I'll post up a reply to you again. AND AGAIN - THANKS for THE REPLY to my question!!!!

Here's another VS tool one of my colleagues found that is particularly useful for managing complex projects especially where there is a mix of C++ and C#: Project Configuration Manager.