4

In Qt Creator, I have a pro file using PRECOMPILED HEADERS.

The build works just perfect when I build in Release mode. But building in Debug mode gives errors, generating object files failing. Example:

17:12:40: Running steps for project Euclide...
17:12:40: Configuration unchanged, skipping qmake step.
17:12:40: Starting: "C:\Qt\Tools\mingw48_32\bin\mingw32-make.exe" 
C:\Qt\5.2.0\mingw48_32\bin\qmake.exe -spec win32-g++ CONFIG+=debug -o Makefile ..\euclide\Euclide.pro
C:/Qt/Tools/mingw48_32/bin/mingw32-make -f Makefile.Debug
mingw32-make[1]: Entering directory 'C:/UserPrograms/Euclide/build'
g++ -c -include debug\_pch.h -pipe -fno-keep-inline-dllexport -std=gnu++11 -g -frtti -Wall -Wextra -fexceptions -mthreads -DUNICODE -DQT_WEBKITWIDGETS_LIB -DQT_MULTIMEDIAWIDGETS_LIB -DQT_QUICK_LIB -DQT_POSITIONING_LIB -DQT_OPENGL_LIB -DQT_PRINTSUPPORT_LIB -DQT_WEBKIT_LIB -DQT_MULTIMEDIA_LIB -DQT_QML_LIB -DQT_WIDGETS_LIB -DQT_NETWORK_LIB -DQT_SENSORS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NEEDS_QMAIN -I..\euclide -I"..\..\..\Program Files (x86)\boost\boost_1_53_0" -I"..\numlib\mathvec" -I"..\..\..\Qt\5.2.0\mingw48_32\include" -I"..\..\..\Qt\5.2.0\mingw48_32\include\QtWebKitWidgets" -I"..\..\..\Qt\5.2.0\mingw48_32\include\QtMultimediaWidgets" -I"..\..\..\Qt\5.2.0\mingw48_32\include\QtQuick" -I"..\..\..\Qt\5.2.0\mingw48_32\include\QtPositioning" -I"..\..\..\Qt\5.2.0\mingw48_32\include\QtOpenGL" -I"..\..\..\Qt\5.2.0\mingw48_32\include\QtPrintSupport" -I"..\..\..\Qt\5.2.0\mingw48_32\include\QtWebKit" -I"..\..\..\Qt\5.2.0\mingw48_32\include\QtMultimedia" -I"..\..\..\Qt\5.2.0\mingw48_32\include\QtQml" -I"..\..\..\Qt\5.2.0\mingw48_32\include\QtWidgets" -I"..\..\..\Qt\5.2.0\mingw48_32\include\QtNetwork" -I"..\..\..\Qt\5.2.0\mingw48_32\include\QtSensors" -I"..\..\..\Qt\5.2.0\mingw48_32\include\QtGui" -I"..\..\..\Qt\5.2.0\mingw48_32\include\QtCore" -I"debug" -I"." -I"." -I"..\..\..\Qt\5.2.0\mingw48_32\mkspecs\win32-g++" -o debug\main.o ..\euclide\main.cpp

Makefile.Debug:1543: recipe for target 'debug/main.o' failed
mingw32-make[1]: *** [debug/main.o] Error 1
mingw32-make[1]: Leaving directory 'C:/UserPrograms/Euclide/build'
makefile:34: recipe for target 'debug' failed
mingw32-make: *** [debug] Error 2
17:12:59: The process "C:\Qt\Tools\mingw48_32\bin\mingw32-make.exe" exited with code 2.
Error while building/deploying project Euclide (kit: Desktop Qt 5.2.0 MinGW 32bit)
When executing step 'Make'
17:12:59: Elapsed time: 00:19.

What is really confusing is that it works fine in Release. I made some tests with a small project and it works fine in Release or Debug modes, but for any reason, a bigger project is failing. It is even impossible to compile a single file of the project in Debug. The pro file is below:

QT += core gui \
    webkitwidgets \
    printsupport

greaterThan(QT_MAJOR_VERSION, 4): QT += widgets

TARGET = Euclide
TEMPLATE = app

QMAKE_CXXFLAGS += -std=gnu++11

CONFIG += precompile_header

# Use Precompiled headers (PCH)
PRECOMPILED_HEADER  = _pch.h    

SOURCES +=  main.cpp\
    mainwindow.cpp \
    zero.cpp \
    ... lot of files here...
    debug_tool.cpp

HEADERS += mainwindow.h \
    zero.h \
    ... lot of files here...
    debug_tool.h \
    _pch.h

FORMS += mainwindow.ui \
    zero.ui \
    ... other files...
    apphelp.ui \
    message.ui

INCLUDEPATH = "C:/Program Files (x86)/boost/boost_1_53_0"

LIBS += \
    ../build/release/exprcompiler.dll

RESOURCES += \
    resources/euclide_resources.qrc

I spent days of extensive resarch on the net to fix this problem but not found any explanation, even if documentation about qmake is complete...

Does anyone know how to fix this problem ? because the only solution I consider now, is to have a special "Debug" version of this all project, without precompiled headers... Thanks for your help.

Hugo
  • 157
  • 2
  • 9
  • Could you please provide a self-contained example reproducing the issue? Please refer to sscce.org for details. – László Papp Jan 09 '14 at 00:31
  • In building your code, does using precompiled headers save a significant amount of time? I tend to use precompiled headers in projects over 30KLOC or on very slow development platforms. The headaches when using them, like you are experiencing, don't justify the waste of time. Or the time gained from using them is wasted in issues like this. – Thomas Matthews Jan 09 '14 at 00:32
  • @ThomasMatthews: someone would not use them without real gain, right? :-) People usually go for it, when they are looking for slow compilation optimization. I cannot possibly imagine any other case for it. – László Papp Jan 09 '14 at 00:46
  • 1
    @Laszlo: The project is (quite) big now, with dozens of files (without counting includes and dll source), so unfortunately I cannot post the code. But really the compile output is giving no explanation except this debug/main.o error 1 on top of my post. Also, small projects work fine in two modes, and I don't know where to find. – Hugo Jan 09 '14 at 01:46
  • @Hugo: if you cannot provide a self-contained code, I am not sure how you would hope for help. I am voting to close this until a minimal teste case is provided. – László Papp Jan 09 '14 at 01:48
  • @Thomas: Yes, PCH saves time, small/big and especially on this project. But in release only... I agree for the headache. – Hugo Jan 09 '14 at 02:23
  • @Laszlo: In fact, all the projects we did, worked perfectly until now, debug or release, with PCH. Except this one. But this project is too big to provide a self-contained code, since we do not know where is the problem, if problem exists really from our side. – Hugo Jan 09 '14 at 02:36
  • So you want each of us taking a look at it to go through your large project question rather than you localizing the issue in your project that you are supposed to familiar with and confirm sscce.org? Does not sound too productive. – László Papp Jan 09 '14 at 02:39
  • I can give code sample, but it will work, like we tested ourself, unable to reproduce the problem on a smaller pgm. -I was thinking that maybe the pro file that I posted above has an error. Apparently it is correct ? -Another thing I was hoping, maybe, is that this typical failure has been experienced by someone who knows the reason. – Hugo Jan 09 '14 at 02:58
  • The problem is not on the code (lines of program) which compiles fast and work fine in Release mode. The problem comes from the Edi, or the chain of compilation, or another reason, not related to the code. At a certain point I was thinking about the pro file, but apparently not. Maybe the PCH database is exhausted/corrupted in debug for any reason; I don't know. Any single file cannot even be compiled one by one in debug. – Hugo Jan 09 '14 at 03:17
  • 1
    @LaszloPapp I think this is an acceptable question, personally. The question is not "Where is the bug in my project", but "What could PCH be causing to go wrong" in a general sense. If it doesn't have a meaningful answer (ie, the answer is "you have a bug in your code") then that's fine, and it won't get a good answer, and might be a candidate for self-closure by the OP. If on the other hand the pre-compiled headers do have a particular issue that one has to address, this might be helpful for others in the future and stands as a reasonable question. – Joe Jan 09 '14 at 04:06
  • I don't see any output from the `g++` command executed by the makefile. Try executing that command (`g++ -c -include debug\_pch.h -pipe -fno-keep-inline-dllexport ... blah blah blah`) from the command line yourself to see if it says anything helpful. Also, I don't see the make process performing the step of pre-compiling the headers. Try deleting all `*.gch` files manually and rerunning things to see if that helps. – Michael Burr Jan 09 '14 at 04:52
  • @Joe: please give technical suggestions if it is "acceptable". I cannot reproduce the issue locally, and I spent quite a bit of time with it. If you are that defensive towards this question, please give a self-contained code, otherwise you are not giving much value to the thread IMO. We are here to resolve the issue, not for being defensive towards ourselves. A self-contained example is a must have to proceed, at least for me. – László Papp Jan 09 '14 at 07:01
  • I have no idea on the topic, not a c++ expert, just commenting on the acceptability of the question from a SE point of view. It seems reasonable to me, in that the question he asked could have an answer with the information given. – Joe Jan 09 '14 at 16:20
  • @LaszloPapp: sorry of the mistake, but I am not expecting you to inspect the code, which is of course too large, and also, confidential. The problem is on Ide & tools when PCH+Debug mode in Qt Creator ! Not the code, which compiles an runs perfect in Release, and also in Debug but without PCH. I am UNABLE to reproduce the problem on a sscce code. Everything works perfect Release+Debug+PCH ! (Also I am still limited in the volume of typing here, unfortunately. I cannot post code.) – Hugo Jan 09 '14 at 16:30
  • @Hugo: if you cannot send a code reproducing the issue, how can you expect help? You should _not_ paste your code, but you _should_ strive for providing an example reproducing this issue. – László Papp Jan 09 '14 at 16:32
  • @Joe: Thanks a lot to understand the interest of the issue and question, that I am not alone to have. – Hugo Jan 09 '14 at 16:40
  • @MichaelBurr: I did what you suggested, and the _pch.h.gch folder has been well rebuilt, with a fresh PCH file "C++" of 142MBytes. So apparently the pre-process works. The g++ commands by the makefile are well done. But when it comes to: ... -o debug\main.o ..\euclide\main.cpp I have the output: Makefile.Debug:1543: recipe for target 'debug/main.o' failed mingw32-make[1]: *** [debug/main.o] Error 1 ... – Hugo Jan 09 '14 at 17:08
  • @hugo: what happens if you enter the `g++` command to compile `main.c` from the command line (ie., not via `make`)? – Michael Burr Jan 09 '14 at 17:39
  • @Michael: I run into errors due to the headers which are organized for PCH... On a small (naive) project it works, but not on this one. So I have to investigate around it. Sorry. – Hugo Jan 09 '14 at 19:17
  • @Hugo: no need to be sorry - I'm just trying to give suggestions that I think may help troubleshoot the problem. – Michael Burr Jan 09 '14 at 19:26

1 Answers1

6

I have (probably) run into the same problem and took some time to find out what is going on.

After some fiddling around to create an MWE I found, that the size of the .pch file seems to be crucial for this problem.

Using a PCH that is greater than 128 MB aborts the compilation without any message and returns code 1 (instead of 0 for succesful compilation).

My findings resemble the problem stated in this GCC mailing list entry.

It seems the only way to get it working is to reduce the size of the PCH file below 128 MB.

Just for the record: I am using a QMake project from Qt 5.2.1 and the included MinGW (rev2) gcc 4.8.0 32bit on WinXP 32bit and Win 8 64bit.

On the other hand my GCC 4.8.2 64bit under linux ate a ~5GB PCH file without complaints (I would have tested a bigger one but compiling this one nearly exceeded my RAM).

Digging deeper

I generated a header file to use as PCH with following contents:

class _1 {};
class _2 {};
class _3 {};
class _4 {};
class _5 {};
class _6 {};
class _7 {};
class _8 {};
class _9 {};
class _10 {};
//...

Using binary search (for the number of classes in this file) I found that filling this file with 128273 classes results in a generated PCH file that has a size of 135266564 bytes and can be used during compilation of other files. Using 128274 classes the generated PCH file has a size of 135270660 bytes and compilation using this PCH fails.

I am not sure what to do with this information. Not giving an error message is definitely wrong but I don't know who is to blame (GCC (version?), MinGW/Windows, 32bitness).

Maybe someone with more time at hand can decide and inform the right people?

  • Great answer! I got the same problem with Qt 5.3.0 (with gcc 4.8.2). Including QtCore, QtGui and QtWidgets to pch (which decreases compilation time a lot) produced 136MB and build failed on first compiled file besides pch. Including only QtCore and QtGui produced 119MB and the build succeeded. – Xilexio Oct 05 '14 at 17:43
  • 2023 and this is still an unresolved issue... qt 5.15.4 and mingw32-g++ 11.3.0 – supernun Jun 27 '23 at 15:03