cmake creates corrupt binaries

Hello,

I was overjoyed when my cmake experiment finally built all subprojects
successfully.
Well - I thought that everything would be fine, since there were no translation
errors - but unfortunately that is not the case.

The generated binary files are corrupt.

This manifests itself in the fact that no constructor is executed when loading
the Qt plugins (variables are not initialized, although programmed that way in
the constructor). Then the debugger jumps to completely wrong source files/
lines - the displayed code does not match the executed one at all.

Now you could assume that I simply programmed badly. Only it is so that if I
build the same source files with qmake, an executable application arises, which
does not have said error with loading of the plugins.

I then imported my handwritten cmake instructions into QtCreator and hoped
that when I compile with QtCreator the defaults might be better set so that
something usable would result. Unfortunately that was not the case.

I had started with cmake, because qmake can’t handle the dependencies. But if
I have to search for unknown errors now, the experiment is too expensive for
me.

Too bad actually. I was looking forward to it, because the story with the
dependencies is definitely better solved with cmake.

I am undecided what I should do.

Any advices?

I would recommend boiling it down to the simplest case that works in qmake and doesn’t work in cmake. I’d also investigate the commands executed by each to see what’s different between them.

There’s just not enough detail here to give any specific guidance as to what is wrong though.

1 Like

Hi,

I would recommend boiling it down to the simplest case that works in qmake
and doesn’t work in cmake.

Hm, some plugins consist of one source file and one header file. There’s nothing
I could boil down.

I’d also investigate the commands executed by each to see what’s different
between them.

Ok, that’s a good advice. So here we go:

What immediately jumps out is the use of different compilers.
cmake uses c++ whereas qmake uses g++
Don’t know how it is in this special case, but several linux tools change
behaviour if called by different names.

Then I compared the commands used to process a single source file. cmake uses
one call, which creates one outputfile, whereas qmake uses 3 commands, which
create two files. cmake additionally compiles a file called mocs_compilation but
I could not find how that is created.

So here’s the cmake compile stage (same command line for every source):

/usr/bin/c++
    -DQT_CORE_LIB
    -DQT_DISABLE_DEPRECATED_BEFORE=0x060000
    -DQT_GUI_LIB
    -DQT_SQL_LIB
    -DQT_UITOOLS_LIB
    -DQT_USE_QSTRINGBUILDER
    -DQT_WIDGETS_LIB
    -DQT_XML_LIB
    -DUSE_PLUGINS
    -I/d/linux/qt/build-FalconView_Test/src/baselib/FVBaseLib_autogen/include
    -I/d/PUBLIC/FalconView/src/baselib/control
    -I/d/PUBLIC/FalconView/src/baselib/model
    -I/d/PUBLIC/FalconView/src/baselib/util
    -I/d/PUBLIC/FalconView/src/baselib/view
    -I/usr/local/src/linuxcnc-deb11/include
    -I/usr/local/src/linuxcnc-deb11/src
    -I/usr/local/src/linuxcnc-deb11/src/emc/rs274ngc
    -I/usr/local/src/linuxcnc-deb11/src/emc/tooldata
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtGui/5.15.2
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtGui/5.15.2/QtGui
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtCore/5.15.2
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtCore/5.15.2/QtCore
    -I/usr/local/include/opencascade
    -isystem /opt/qt5.15/5.15.2/gcc_64/include
    -isystem /opt/qt5.15/5.15.2/gcc_64/include/QtGui
    -isystem /opt/qt5.15/5.15.2/gcc_64/include/QtCore
    -isystem /opt/qt5.15/5.15.2/gcc_64/./mkspecs/linux-g++
    -isystem /opt/qt5.15/5.15.2/gcc_64/include/QtWidgets
    -isystem /opt/qt5.15/5.15.2/gcc_64/include/QtSql
    -isystem /opt/qt5.15/5.15.2/gcc_64/include/QtUiTools
    -isystem /opt/qt5.15/5.15.2/gcc_64/include/QtXml
    -g
    -fPIC
    -std=gnu++17
    -o
    CMakeFiles/FVBaseLib.dir/control/core.cpp.o
    -c
    /d/PUBLIC/FalconView/src/baselib/control/core.cpp

qmake starts with similar compile command:

g++
    -c
    -pipe
    -g
    -fPIC
    -std=gnu++1z
    -Wall
    -Wextra
    -D_REENTRANT
    -DQT_DISABLE_DEPRECATED_BEFORE=0x060000
    -DQT_USE_QSTRINGBUILDER
    -DUSE_PLUGINS
    -DQT_QML_DEBUG
    -DQT_UITOOLS_LIB
    -DQT_WIDGETS_LIB
    -DQT_GUI_LIB
    -DQT_SQL_LIB
    -DQT_XML_LIB
    -DQT_CORE_LIB
    -I../../../FalconView/src/baselib
    -I.
    -I../../../FalconView/src/baselib/model
    -I../../../FalconView/src/baselib/control
    -I../../../FalconView/src/baselib/util
    -I../../../FalconView/src/baselib/view
    -I/usr/include/python3.9
    -I/usr/local/src/linuxcnc-deb11/include
    -I/usr/local/src/linuxcnc-deb11/src/emc/rs274ngc
    -I/usr/local/src/linuxcnc-deb11/src/emc/tooldata
    -I/usr/local/src/linuxcnc-deb11/src
    -I/usr/local/include/opencascade
    -I/opt/qt5.15/5.15.2/gcc_64/include
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtUiTools
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtWidgets
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtGui/5.15.2
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtGui/5.15.2/QtGui
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtGui
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtCore/5.15.2
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtCore/5.15.2/QtCore
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtSql
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtXml
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtCore
    -I.
    -I/usr/include/libdrm
    -I/opt/qt5.15/5.15.2/gcc_64/mkspecs/linux-g++
    -o
    kernel.o
    ../../../FalconView/src/baselib/control/kernel.cpp

But then qmake adds a moc-comand followed by a compile stage:

/opt/qt5.15/5.15.2/gcc_64/bin/moc
    -DQT_DISABLE_DEPRECATED_BEFORE=0x060000
    -DQT_USE_QSTRINGBUILDER
    -DUSE_PLUGINS
    -DQT_QML_DEBUG
    -DQT_UITOOLS_LIB
    -DQT_WIDGETS_LIB
    -DQT_GUI_LIB
    -DQT_SQL_LIB
    -DQT_XML_LIB
    -DQT_CORE_LIB
    --include
    /d/PUBLIC/build-FalconView_Multi-Desktop_Qt_5_15_2_GCC_64bit-Debug/src/
baselib/moc_predefs.h
    -I/opt/qt5.15/5.15.2/gcc_64/mkspecs/linux-g++
    -I/d/PUBLIC/FalconView/src/baselib
    -I/d/PUBLIC/FalconView/src/baselib/model
    -I/d/PUBLIC/FalconView/src/baselib/control
    -I/d/PUBLIC/FalconView/src/baselib/util
    -I/d/PUBLIC/FalconView/src/baselib/view
    -I/usr/include/python3.9
    -I/usr/local/src/linuxcnc-deb11/include
    -I/usr/local/src/linuxcnc-deb11/src/emc/rs274ngc
    -I/usr/local/src/linuxcnc-deb11/src/emc/tooldata
    -I/usr/local/src/linuxcnc-deb11/src
    -I/usr/local/include/opencascade
    -I/opt/qt5.15/5.15.2/gcc_64/include
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtUiTools
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtWidgets
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtGui/5.15.2
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtGui/5.15.2/QtGui
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtGui
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtCore/5.15.2
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtCore/5.15.2/QtCore
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtSql
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtXml
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtCore
    -I.
    -I/usr/include/c++/10
    -I/usr/include/x86_64-linux-gnu/c++/10
    -I/usr/include/c++/10/backward
    -I/usr/lib/gcc/x86_64-linux-gnu/10/include
    -I/usr/local/include
    -I/usr/include/x86_64-linux-gnu
    -I/usr/include
    ../../../FalconView/src/baselib/control/kernel.h
    -o
    moc_kernel.cpp

… and the compile stage:

g++
    -c
    -pipe
    -g
    -fPIC
    -std=gnu++1z
    -Wall
    -Wextra
    -D_REENTRANT
    -DQT_DISABLE_DEPRECATED_BEFORE=0x060000
    -DQT_USE_QSTRINGBUILDER
    -DUSE_PLUGINS
    -DQT_QML_DEBUG
    -DQT_UITOOLS_LIB
    -DQT_WIDGETS_LIB
    -DQT_GUI_LIB
    -DQT_SQL_LIB
    -DQT_XML_LIB
    -DQT_CORE_LIB
    -I../../../FalconView/src/baselib
    -I.
    -I../../../FalconView/src/baselib/model
    -I../../../FalconView/src/baselib/control
    -I../../../FalconView/src/baselib/util
    -I../../../FalconView/src/baselib/view
    -I/usr/include/python3.9
    -I/usr/local/src/linuxcnc-deb11/include
    -I/usr/local/src/linuxcnc-deb11/src/emc/rs274ngc
    -I/usr/local/src/linuxcnc-deb11/src/emc/tooldata
    -I/usr/local/src/linuxcnc-deb11/src
    -I/usr/local/include/opencascade
    -I/opt/qt5.15/5.15.2/gcc_64/include
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtUiTools
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtWidgets
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtGui/5.15.2
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtGui/5.15.2/QtGui
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtGui
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtCore/5.15.2
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtCore/5.15.2/QtCore
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtSql
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtXml
    -I/opt/qt5.15/5.15.2/gcc_64/include/QtCore
    -I.
    -I/usr/include/libdrm
    -I/opt/qt5.15/5.15.2/gcc_64/mkspecs/linux-g++
    -o
    moc_kernel.o
    moc_kernel.cpp

a look at the creation of a library reveals the reason for the different file
sizes:
First the cmake variant:

/usr/bin/ar qc libFVBaseLib.a
    CMakeFiles/FVBaseLib.dir/FVBaseLib_autogen/mocs_compilation.cpp.o
    CMakeFiles/FVBaseLib.dir/control/core.cpp.o
    CMakeFiles/FVBaseLib.dir/control/kernel.cpp.o
    CMakeFiles/FVBaseLib.dir/model/configacc.cpp.o
    CMakeFiles/FVBaseLib.dir/model/configmgr.cpp.o
    CMakeFiles/FVBaseLib.dir/model/direntry.cpp.o
    CMakeFiles/FVBaseLib.dir/model/dirmodel.cpp.o
    CMakeFiles/FVBaseLib.dir/model/filemodel.cpp.o
    CMakeFiles/FVBaseLib.dir/model/sysevent.cpp.o
    CMakeFiles/FVBaseLib.dir/model/syseventmodel.cpp.o
    CMakeFiles/FVBaseLib.dir/model/valuemanager.cpp.o
    CMakeFiles/FVBaseLib.dir/model/valuemodel.cpp.o
    CMakeFiles/FVBaseLib.dir/util/dbconnection.cpp.o
    CMakeFiles/FVBaseLib.dir/util/flowlayout.cpp.o
    CMakeFiles/FVBaseLib.dir/util/kernelcreator.cpp.o
    CMakeFiles/FVBaseLib.dir/util/timestamp.cpp.o

followed by:

/usr/bin/ranlib libFVBaseLib.a

… whereas qmake builds a library like this:

ar cqs ../libbaselib.a
    core.o
    kernel.o
    configacc.o
    configmgr.o
    direntry.o
    dirmodel.o
    filemodel.o
    sysevent.o
    syseventmodel.o
    valuemanager.o
    valuemodel.o
    dbconnection.o
    flowlayout.o
    kernelcreator.o
    timestamp.o
    moc_kernel.o
    moc_dirmodel.o
    moc_filemodel.o
    moc_sysevent.o
    moc_syseventmodel.o
    moc_valuemodel.o

Last not least the linking of the application:
cmake does it this way:

/usr/bin/c++
    -g
    CMakeFiles/FalconView.dir/FalconView_autogen/mocs_compilation.cpp.o
    CMakeFiles/FalconView.dir/main.cpp.o
    CMakeFiles/FalconView.dir/control/abstractcondition.cpp.o
    CMakeFiles/FalconView.dir/control/andcondition.cpp.o
    CMakeFiles/FalconView.dir/control/dynaaction.cpp.o
    CMakeFiles/FalconView.dir/control/equalcondition.cpp.o
    CMakeFiles/FalconView.dir/control/falsecondition.cpp.o
    CMakeFiles/FalconView.dir/control/greatercondition.cpp.o
    CMakeFiles/FalconView.dir/control/mainwindow.cpp.o
    CMakeFiles/FalconView.dir/control/multistatetoolbutton.cpp.o
    CMakeFiles/FalconView.dir/control/notcondition.cpp.o
    CMakeFiles/FalconView.dir/control/orcondition.cpp.o
    CMakeFiles/FalconView.dir/control/smallercondition.cpp.o
    CMakeFiles/FalconView.dir/control/testmain.cpp.o
    CMakeFiles/FalconView.dir/control/truecondition.cpp.o
    CMakeFiles/FalconView.dir/model/falconviewdb.cpp.o
    CMakeFiles/FalconView.dir/model/tool.cpp.o
    CMakeFiles/FalconView.dir/model/toolcategory.cpp.o
    CMakeFiles/FalconView.dir/util/multistateaction.cpp.o
    CMakeFiles/FalconView.dir/view/dockable.cpp.o
    CMakeFiles/FalconView.dir/view/micon.cpp.o
    CMakeFiles/FalconView.dir/view/plugindialog.cpp.o
    -o FalconView
    -Wl,-rpath,/usr/local/src/linuxcnc-deb11/lib:/opt/qt5.15/5.15.2/gcc_64/
lib:/usr/local/lib
    ../baselib/libFVBaseLib.a
    ../lcLib/libFVlcLib.a
    /usr/local/src/linuxcnc-deb11/lib/liblinuxcnc.a
    /usr/local/src/linuxcnc-deb11/lib/libposemath.so
    /usr/local/src/linuxcnc-deb11/lib/libnml.so
    /usr/local/src/linuxcnc-deb11/lib/librs274.so
    /usr/local/src/linuxcnc-deb11/lib/liblinuxcncini.so
    /usr/local/src/linuxcnc-deb11/lib/libpyplugin.so
    /usr/local/src/linuxcnc-deb11/lib/liblinuxcnchal.so
    /usr/local/src/linuxcnc-deb11/lib/libtooldata.so
    -lm
    -lstdc++
    -lboost_python39
    -lpython3.9
    -lcrypt
    -lpthread
    -ldl
    -lutil
    -lTKIGES
    -lTKSTL
    -lTKVRML
    -lTKSTEP
    -lTKSTEPAttr
    -lTKSTEP209
    -lTKSTEPBase
    -lTKXSBase
    ../baselib/libFVBaseLib.a
    /opt/qt5.15/5.15.2/gcc_64/lib/libQt5Sql.so.5.15.2
    /opt/qt5.15/5.15.2/gcc_64/lib/libQt5UiTools.a
    /opt/qt5.15/5.15.2/gcc_64/lib/libQt5Widgets.so.5.15.2
    /opt/qt5.15/5.15.2/gcc_64/lib/libQt5Gui.so.5.15.2
    /opt/qt5.15/5.15.2/gcc_64/lib//libQt5Widgets.so
    /opt/qt5.15/5.15.2/gcc_64/lib//libQt5Gui.so
    /opt/qt5.15/5.15.2/gcc_64/lib//libQt5Core.so
    /opt/qt5.15/5.15.2/gcc_64/lib//libQt5Widgets.so
    /opt/qt5.15/5.15.2/gcc_64/lib//libQt5Gui.so
    /opt/qt5.15/5.15.2/gcc_64/lib//libQt5Core.so
    -lpthread
    /usr/lib/x86_64-linux-gnu/libGL.so
    /opt/qt5.15/5.15.2/gcc_64/lib/libQt5Xml.so.5.15.2
    /opt/qt5.15/5.15.2/gcc_64/lib/libQt5Core.so.5.15.2
    /usr/local/lib/libTKOpenGl.so.7.6.0
    /usr/local/lib/libTKOffset.so.7.6.0
    /usr/local/lib/libTKFillet.so.7.6.0
    /usr/local/lib/libTKBool.so.7.6.0
    /usr/local/lib/libTKVCAF.so.7.6.0
    /usr/local/lib/libTKV3d.so.7.6.0
    /usr/local/lib/libTKService.so.7.6.0
    -lfontconfig
    /usr/local/lib/libTKHLR.so.7.6.0
    /usr/local/lib/libTKMesh.so.7.6.0
    /usr/lib/x86_64-linux-gnu/libfreetype.so
    -lGL
    -lX11
    /usr/local/lib/libTKBin.so.7.6.0
    /usr/local/lib/libTKBinL.so.7.6.0
    /usr/local/lib/libTKXml.so.7.6.0
    /usr/local/lib/libTKCAF.so.7.6.0
    /usr/local/lib/libTKBO.so.7.6.0
    /usr/local/lib/libTKShHealing.so.7.6.0
    /usr/local/lib/libTKPrim.so.7.6.0
    /usr/local/lib/libTKTopAlgo.so.7.6.0
    /usr/local/lib/libTKGeomAlgo.so.7.6.0
    /usr/local/lib/libTKBRep.so.7.6.0
    /usr/local/lib/libTKGeomBase.so.7.6.0
    /usr/local/lib/libTKG3d.so.7.6.0
    /usr/local/lib/libTKG2d.so.7.6.0
    /usr/local/lib/libTKXmlL.so.7.6.0
    /usr/local/lib/libTKMath.so.7.6.0
    /usr/local/lib/libTKLCAF.so.7.6.0
    /usr/local/lib/libTKCDF.so.7.6.0
    /usr/local/lib/libTKernel.so.7.6.0
    -lrt
    -lm
    -lstdc++
    -lboost_python39
    -lpython3.9
    -lcrypt
    -lpthread
    -ldl
    -lutil
    -lTKIGES
    -lTKSTL
    -lTKVRML
    -lTKSTEP
    -lTKSTEPAttr
    -lTKSTEP209
    -lTKSTEPBase
    -lTKXSBase

… whereas qmake does this:

g++
    -Wl,-rpath,/opt/qt5.15/5.15.2/gcc_64/lib
    -Wl,-rpath-link,/opt/qt5.15/5.15.2/gcc_64/lib
    -o FalconView
    main.o
    abstractcondition.o
    andcondition.o
    dynaaction.o
    equalcondition.o
    falsecondition.o
    greatercondition.o
    mainwindow.o
    multistatetoolbutton.o
    notcondition.o
    orcondition.o
    smallercondition.o
    testmain.o
    truecondition.o
    falconviewdb.o
    tool.o
    toolcategory.o
    multistateaction.o
    dockable.o
    micon.o
    plugindialog.o
    qrc_FalconView.o
    moc_tool.o
    moc_toolcategory.o
    moc_dynaaction.o
    moc_equalcondition.o
    moc_falsecondition.o
    moc_greatercondition.o
    moc_mainwindow.o
    moc_multistatetoolbutton.o
    moc_notcondition.o
    moc_orcondition.o
    moc_smallercondition.o
    moc_testmain.o
    moc_truecondition.o
    moc_abstractcondition.o
    moc_andcondition.o
    moc_multistateaction.o
    moc_plugindialog.o
    -Wl,-rpath=/usr/local/src/linuxcnc-deb11/lib
    -L..
    -llcLib
    -L/home/qt/openssl-1.1.1g/lib
    -lbaselib
    -L/usr/local/src/linuxcnc-deb11/lib
    -L/usr/lib
    -lm
    -llinuxcnc
    -lposemath
    -lnml
    -lrs274
    -llinuxcncini
    -lpyplugin
    -llinuxcnchal
    -ltooldata
    -lstdc++
    -lboost_python39
    -lpython3.9
    -lcrypt
    -ldl
    -lutil
    -Wl,-rpath=/usr/local/lib
    -L/usr/local/lib
    -lTKernel
    -lTKMath
    -lTKService
    -lTKV3d
    -lTKOpenGl
    -lTKBRep
    -lTKIGES
    -lTKSTL
    -lTKVRML
    -lTKSTEP
    -lTKSTEPAttr
    -lTKSTEP209
    -lTKSTEPBase
    -lTKGeomBase
    -lTKGeomAlgo
    -lTKG3d
    -lTKG2d
    -lTKXSBase
    -lTKShHealing
    -lTKHLR
    -lTKTopAlgo
    -lTKMesh
    -lTKPrim
    -lTKCDF
    -lTKBool
    -lTKBO
    -lTKFillet
    -lTKOffset
    -lTKLCAF
    -lTKCAF
    -lTKVCAF
    -lTKBin
    -lTKXml
    /opt/qt5.15/5.15.2/gcc_64/lib/libQt5UiTools.a
    /opt/qt5.15/5.15.2/gcc_64/lib/libQt5Widgets.so
    /opt/qt5.15/5.15.2/gcc_64/lib/libQt5Gui.so
    /opt/qt5.15/5.15.2/gcc_64/lib/libQt5Sql.so
    /opt/qt5.15/5.15.2/gcc_64/lib/libQt5Xml.so
    /opt/qt5.15/5.15.2/gcc_64/lib/libQt5Core.so
    -lGL
    -lpthread

Did you use set(CMAKE_AUTOMOC ON)? Quoting the Qt CMake docs:

The CMAKE_AUTOMOC setting runs moc automatically when required.
For more details, see CMake AUTOMOC documentation.

See also CMake AUTOMOC docs. I strongly recommend taking a good look at the Qt CMake tutorial over at the Qt docs: Also check out Qt’s blog; they’ve got several posts that talk about CMake, you can pick up a trick or two there.

FYI, we use CMake for most of our Qt C++ projects at work (without QtCreator), and it works swell. You’ll notice that Qt itself embraces CMake, and promotes its use; there is nothing “broken” with CMake’s Qt support.

Also note: Qt 6 has dropped qmake; only CMake is supported for Qt 6.

Use CMAKE_CXX_COMPILER to select your preferred compiler. You can specify it on the command line using -DCMAKE_CXX_COMPILER=/path/to/g++

Hi,

thank you for your attention.

Did you use set(CMAKE_AUTOMOC ON)?

Yes of cause. I created empty projects of each type with QtCreator 6 so I had
a template I could copy from.

When you read my last post, you’ll note, that I wrote about
mocs_compilation files and their usage.

… any way - I suspect, that’s the source of trouble.
Looking at baselib - that mocs_compilation file for 15 source files has nearly
the same size, than one of the moc-files, qmake creates for every source file
(well every source file, that uses QObject).

You’ll notice that Qt itself embraces CMake, and promotes its use;
there is nothing “broken” with CMake’s Qt support.

Hm, I know too little, so i can neither confirm nor deny it.

Also note: Qt 6 has dropped qmake; only CMake is supported for Qt 6.

Don’t know what you mean with “dropped support”. In Qt 6 cmake is default
build system. But QtCreator 6 is stil able to create qmake projects and i.e.
if you create a subdirectory project, then you don’t have the chance to use
cmake. It’s qmake project hardcoded. That does not look to me like dropped
support.

What has given rise to my suspicion of “poor support” is the fact, that cmake-
projects created with QtCreator 6 did not work outside of QtCreator.

Once again, I strongly suggest you walk through the official Qt CMake tutorial. You’ll learn how to create CMake files from scratch, without using QtCreator.

The “root page” for the Qt 5.15 docs links directly to the Build with CMake section. Qt has got several tutorials and examples, in addition to several blog posts regarding Qt and CMake.

Sorry, that was a little bit rushed; they have not dropped qmake support (yet), but note the text from the 6.0 release changelog:

Building Qt from sources now requires CMake and Ninja. See Build System
Changes in Qt 6 for more details on this and other changes in configure.

I’d call the sum of this embracing CMake and promoting its CMake. Maybe it’s subjective.

Hi,

Once again, I strongly suggest you walk through the official Qt CMake
tutorial. You’ll learn how to create CMake files from scratch, without
using QtCreator.

I already skimmed qt about cmake info. Didn’t find much.
Learned much more by cmake docs and of cause SO.
My project has almoust 20 subprojects and all cmake stuff is handwritten.

See also [CMake AUTOMOC docs](https://cmake.org/cmake/help/latest/manual/
cmake-qt.7.html#automoc).

Hm, moc thingy is hidden by cmake autogen - so don’t know, if that behaviour
is ok.

I only see the misbehaviour of debugger and crashing application. But I don’t
know, if debugger only shows wrong context, or if the application jumps to
completely wrong code.

All you’ve done is say “things aren’t working” with vague hand-waves towards what you’ve done instead of specific details as to what is happening and what code you have tried. We’re not experts in your project and (generally) have no time to get into it to figure out what might be wrong with just links to the repositor. Sure, you don’t want (and shouldn’t need to) become a build system expert, but we need to meet somewhere in the middle to figure out what is happening here. Simplifying the problem with a smaller case study that still exhibits the problem would be helpful for both of us (as it may also show what a working project looks like which you could apply to your project).

I’ve yet to see specific error messages that you’re getting and instead am only getting your interpretations; “corrupt” is meaningless for figuring out what is actually happening. The commands you posted look fine, but I have no idea if they’re the ones that are causing the error you’re seeing. I have doubts to that because these don’t look like plugin link lines at least, so how this indicates a corrupt plugin is unclear to me.

1 Like

You’re absolutely right!
… and I did not expect you doing my job!

The point is, I don’t get build errors. Even if I search the build log, there’s nothing strange to me. If you like, I could post a build log here. Didn’t take it as good idea.

Problems arise, when I run the application. It crashes. So I start the app in QtCreator in debug mode. Having built the entire project ensures, that QtCreator does not start doing unwanted things like starting a recompile …

When the debugger stops at the crash, I start to examine current state and from there try to go back on stack to see, what really happened. Then I set breakpoints and restart the debugger to closer examine what happened.
From that I can say, that the debugger does not follow the displayed code.

I called that “corrupt binary”, but ok, may have different cause. I don’t know. And I’m no expert with debugger or build system. I just wonna use that.

… and Yes, I don’t know how to bring debugger output/session into forum and stil being meaningful. I only can describe what I see with my (possibly wrong) words.

Well, I started with prototypes for each subproblem and when its solved I start integrating it into the big project. From then on its nearly impossible to go back. And acutally I’m facing problems sourced by the size of the project.
I could show a single plugin - but as my plugins are application pages, they need the whole application working.

What would you say in my place if the application works built by qmake and crashes built by cmake?

P.S.: any idea, why I don’t receive mails of new posts any more?

This sounds like memory corruption overwriting things. Or the debugger is just lost. Not sure. Does valgrind have any input on what is happening?

Do you have the compile and link lines for the plugin that fails to compare between the qmake and cmake builds?

Do you have the compile and link lines for the plugin that fails to compare
between the qmake and cmake builds?

Its a single source plugin, so I attach the whole build.log of that plugin.

build.log (8.97 KB)

Hi,

Does valgrind have any input on what is happening?

Thank you for that trigger. I know valgrind. Nevertheless, I have to admit
that I use it far too rarely.

Don’t know, whether its ok here to ask for help. I can’t interpret the output
of valgrind. I occurs very often and its related to my “overridden singleton”.

This is the output of valgrind:

==192232==  Uninitialised value was created by a heap allocation
==192232==    at 0x483877F: malloc (vg_replace_malloc.c:307)
==192232==    by 0x611782C: QArrayData::allocate(unsigned long, unsigned long, 
unsigned long, QFlags<QArrayData::AllocationOption>) (qarraydata.cpp:218)
==192232==    by 0x619AF58: allocate (qarraydata.h:225)
==192232==    by 0x619AF58: QString::reallocData(unsigned int, bool) 
(qstring.cpp:2371)
==192232==    by 0x619B057: QString::resize(int) (qstring.cpp:2288)
==192232==    by 0x619E972: QString::setUnicode(QChar const*, int) 
(qstring.cpp:5687)
==192232==    by 0x63846CA: QTextStream::readLineInto(QString*, long long) 
(qtextstream.cpp:1725)
==192232==    by 0x638498D: QTextStream::readLine(long long) (qtextstream.cpp:
1676)
==192232==    by 0x199941: LcProperties::processFile(QFile&) 
(lcproperties.cpp:124)
==192232==    by 0x198E35: LcProperties::LcProperties(QString const&) 
(lcproperties.cpp:14)
==192232==    by 0x18BEFB: GuiKernel::initialize(QLocale const&, DBHelper&) 
(guikernel.cpp:78)
==192232==    by 0x171791: Core::Core(QString const&, QString const&, QLocale 
const&, DBHelper&, QString const&) (core.cpp:21)
==192232==    by 0x189855: GuiCore::GuiCore(QString const&, QString const&, 
QLocale const&, DBHelper&, QString const&) (guicore.cpp:36)

I don’t know, where that heap allocation happens.
guicore.cpp:36 is the initialization call of that singleton (GuiCore is the subclass of the singletons accessor/wrapper). That call exists once in the application. Exactly at main.cpp:64

GuiCore::setKernelCreator(new GuiKernelCreator());
GuiCore      appCore(iniFileName, "FalconView", curLocale, dbHelper);

First line creates a factory and adds it to the singleton.
Second line calls the initialization constructor (guicore.cpp:36)

GuiCore::GuiCore(const QString& iniFileName, const QString& appName, const 
QLocale& locale, DBHelper& dbAssist, const QString& groupID)
 : Core(iniFileName, appName, locale, dbAssist, groupID) {
  }

Second line is line 36 which valgrind blames.
Next step is core.cpp:21 - the singletons accessor wrapper base class:

Core::Core(const QString& iniFileName, const QString& appName, const QLocale& 
locale, DBHelper& dbAssist, const QString& group) {
  if (!kernel) {
     assert(kc);
     kernel = kc->kernel(iniFileName, appName, group);
     kernel->initialize(locale, dbAssist);
     }
  }

Line 21 is the call to initialize.
Explaining the constructor:

  • kc is the factory set at main.
  • kernel is the static pointer of the singleton

next blamed line is guikernel.cpp:78 - guikernel is the private class of the
singleton static part, which extends Kernel.

void GuiKernel::initialize(const QLocale& locale, DBHelper &dbAssist) {
  Kernel::initialize(locale, dbAssist);
  lcProps = new LcProperties(fileName);

last line is line 78

  • lcProps is a member pointer (initialized to 0 at constructor call).
  • fileName is a member of superclass (Kernel) set at initialization constructor
    call from main

constructor of LcProperties is lcproperties.cpp:14

LcProperties::LcProperties(const QString& fileName)
 : curMap(nullptr)
 , fn(fileName) {
  QFile file(fileName);

  if (file.exists()) processFile(file);
  }

line 14 is the call to processFile, which is next blamed line
(lcproperties.cpp:124):

  if (file.open(QIODevice::ReadOnly | QIODevice::Text)) {
     QTextStream in(&file);
     QString line = in.readLine();

     while (!line.isNull()) {
           processLine(line);
           line = in.readLine();
           }
     file.close();
     }

line 124 is the call to QTextStream::readLine …

Its a long way to here and now it dives into Qt code.
I expect the blamed error is in the above code parts, but I can’t see it.