Repository navigation
Missing generated wrappers for RHEL 9 CI tasks #291
Description
The wrapper generation in CI tasks for oldschool builds (RHEL9) fails:
Trying to determine Qt version...
Determined Qt version is 5.15.9
Parsing typesystem file [:/trolltech/generator/build_all.txt]
/usr/include/qt5ln/include/QtCore/qconfig.h:19: #error: #error "unexpected value for __WORDSIZE macro"
PreProcessing - Generate [.preprocessed.tmp] using [:/trolltech/generator/qtscript_masterinclude.h] and include-paths []
/usr/include/qt5ln/include/QtCore/qsystemdetection.h:184: #error: #error "Qt has not been ported to this OS - see http://www.qt-project.org/"
/usr/include/qt5ln/include/QtCore/qcompilerdetection.h:504: #error: #error "Qt has not been tested with this compiler - see http://www.qt-project.org/"
/usr/include/qt5ln/include/QtCore/qcompilerdetection.h:590: #error: #error Qt requires a C++11 compiler and yours does not seem to be that.
/usr/include/qt5ln/include/QtCore/qbasicatomic.h:61: #error: #error "Qt requires C++11 support"
/usr/include/qt5ln/include/QtCore/qglobalstatic.h:60: syntax error: failed to evaluate #if condition, division/modulo by zero
Building model using [.preprocessed.tmp]
Classes in typesystem: 0
Generated:
- header....: 0 (0)
- impl......: 0 (0)
- modules...: 0 (0)
- pri.......: 0 (0)
This has not been noticed before because it currently does not generate a CI failure.
Activity
Let the CI fail if no wrappers are generated
Let the CI fail if no wrappers are generated
Let the CI fail if no wrappers are generated
hjmjohnson commentedon Sep 29, 2025
This may be addressed with the work done in #313.
jcfr commentedon Sep 29, 2025
After inspecting the output of the associated job1, it looks like the problem still persists:
Footnotes
https://github.com/MeVisLab/pythonqt/actions/runs/18106650418/job/51522795026?pr=313#step:6:22 ↩
mrbean-bremen commentedon Sep 29, 2025
Yes. I had a look at this some time ago, and the problem is that for some reason some features (like
QT_FEATURE_thread) are not defined inqtscript_masterinclude.h, and theQT_CONFIGmacro than barks on the feature by causing a division by zero (it does this intentionally to ensure that the features are defined). Something goes wrong during configuration.I experimentally added a workaround, basically defining QT_BOOTSTRAPPED and redefining QT_CONFIG, which worked to a point, but it generated less wrappers than expected because some features were not defined (as to be expected).
I didn't dig further into this so far, though.
ci: Fix generation of wrappers on rockylinux multi-lib distribution
jcfr commentedon Sep 30, 2025
Et voila. This should now be fixed 🚀
mrbean-bremen commentedon Sep 30, 2025
Excellent, merci!
So
/usr/includewas missing, I hadn't seen this...jcfr commentedon Sep 30, 2025
Technically, we could have addressed this by defining
__WORDSIZEto64ingenerator/qtscript_masterinclude.h1 so thatqconfig-multilib.h2 ends up includingQtCore/qconfig-64.h. That said, I considered this as a hack specific to the packaging of Qt on Rocky Linux.Instead, I opted to implement two changes ...
__x86_64__in commitfix(generator): Define __x86_64__ to support Qt SDK on multi-lib distribution(only ifQ_PROCESSOR_X86_64is itself defined)--include-paths=/usr/includein the follow-up commit to ensure that headerbits/wordsize.hincluded inqconfig-multilib.h2 is found on Rocky Linux and can define__WORDSIZEby checking if__x86_64__is itself defined.Footnotes
https://github.com/MeVisLab/pythonqt/blob/master/generator/qtscript_masterinclude.h ↩
https://git.rockylinux.org/staging/rpms/qt5-qtbase/-/blob/r8/SOURCES/qconfig-multilib.h ↩ ↩2
jcfr commentedon Sep 30, 2025
In the future, we could look into (optionally) forwarding
-Ddefines associated with the host system (or target in the context of cross compilation) so that we address most (if not all#error) current reported by the preprocessor.ci: Fix generation of wrappers on rockylinux multi-lib distribution