After update to python-3.11.5, I performed a rebuild of packages dependent on python. Package dev-python/pyside2-5.15.10, built successfully on previous occassions, now consistently fails to build citing a failure in building `${S}/pyside-setup-opensource-src-5.15.10/sources/pyside2_build-python3_11/PySide2/QtGui/PySide2/QtGui/qdragmoveevent_wrapper.cpp` Unable to downgrade python to confirm isolation of problem. Python - 3.11.5 Clang/LLVM - 16.0.6 CMake - 3.26.5-r2 Ninja - 1.11.1-r2 Reproducible: Always A search of Qt Bugs system did not reveal any relevant information. A FreeBSD bug report (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270715) gave a similar problem output. However, suggested fix (patching qtgui/qtwidget header files - https://github.com/OpenMandrivaAssociation/qt5-qtbase/blob/master/qtbase-5.15.9-work-around-pyside2-brokenness.patch) did not correct situation. Similar reporting was also found at LinuxQuestions thread (https://www.linuxquestions.org/questions/slackware-14/freecad-headaches-broken-pyside2-and-qt-needs-to-be-upgraded-to-qt6-4175727965/#post6447665). No viable workaround was given or had not been tried. A search of https://repology.org/ for other distributions using pyside 5.15.10 and that might have patches to workaround issue found were unsuccessful.
Created attachment 868793 [details] build log
Created attachment 868794 [details] output emerge --info
Created attachment 868795 [details] output emerge -pqv
Created attachment 868796 [details] portage environment
FAILED: PySide2/QtGui/CMakeFiles/QtGui.dir/PySide2/QtGui/qdragmoveevent_wrapper.cpp.o /usr/bin/g++ -DPYSIDE_QML_SUPPORT=1 -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQtGui_EXPORTS -I/var/tmp/portage/dev-python/pyside2-5.15.10/work/pyside-setup-opensource-src-5.15.10/sources/pyside2/PySide2/QtGui/QtGui -I/var/tmp/portage/dev-python/pyside2-5.15.10/work/pyside-setup-opensource-src-5.15.10/sources/pyside2/PySide2/QtGui -I/var/tmp/portage/dev-python/pyside2-5.15.10/work/pyside-setup-opensource-src-5.15.10/sources/pyside2_build-python3_11/PySide2/QtGui -I/var/tmp/portage/dev-python/pyside2-5.15.10/work/pyside-setup-opensource-src-5.15.10/sources/pyside2/PySide2 -I/var/tmp/portage/dev-python/pyside2-5.15.10/work/pyside-setup-opensource-src-5.15.10/sources/pyside2/libpyside -I/var/tmp/portage/dev-python/pyside2-5.15.10/work/pyside-setup-opensource-src-5.15.10/sources/pyside2_build-python3_11/PySide2/QtCore/PySide2/QtCore -isystem /usr/include/qt5 -isystem /usr/include/qt5/QtCore -isystem /usr/lib64/qt5/mkspecs/linux-g++ -isystem /usr/include/qt5/QtGui -isystem /usr/include/shiboken2 -isystem /usr/include/python3.11 -march=bdver1 -O2 -pipe -Wall -fvisibility=hidden -Wno-strict-aliasing -std=gnu++11 -fPIC -fPIC -fPIC -MD -MT PySide2/QtGui/CMakeFiles/QtGui.dir/PySide2/QtGui/qdragmoveevent_wrapper.cpp.o -MF PySide2/QtGui/CMakeFiles/QtGui.dir/PySide2/QtGui/qdragmoveevent_wrapper.cpp.o.d -o PySide2/QtGui/CMakeFiles/QtGui.dir/PySide2/QtGui/qdragmoveevent_wrapper.cpp.o -c /var/tmp/portage/dev-python/pyside2-5.15.10/work/pyside-setup-opensource-src-5.15.10/sources/pyside2_build-python3_11/PySide2/QtGui/PySide2/QtGui/qdragmoveevent_wrapper.cpp In file included from /var/tmp/portage/dev-python/pyside2-5.15.10/work/pyside-setup-opensource-src-5.15.10/sources/pyside2_build-python3_11/PySide2/QtGui/PySide2/QtGui/qdragmoveevent_wrapper.cpp:63: /var/tmp/portage/dev-python/pyside2-5.15.10/work/pyside-setup-opensource-src-5.15.10/sources/pyside2_build-python3_11/PySide2/QtGui/PySide2/QtGui/qdragmoveevent_wrapper.h:55:235: error: ‘DragMove’ is not a member of ‘QOpenGLShader’ 55 | QDragMoveEventWrapper(const QPoint & pos, QFlags<Qt::DropAction> actions, const QMimeData * data, QFlags<Qt::MouseButton> buttons, QFlags<Qt::KeyboardModifier> modifiers, QFlags<QOpenGLShader::ShaderTypeBit> type = QOpenGLShader::DragMove); | ^~~~~~~~ /var/tmp/portage/dev-python/pyside2-5.15.10/work/pyside-setup-opensource-src-5.15.10/sources/pyside2_build-python3_11/PySide2/QtGui/PySide2/QtGui/qdragmoveevent_wrapper.cpp: In constructor ‘QDragMoveEventWrapper::QDragMoveEventWrapper(const QPoint&, QFlags<Qt::DropAction>, const QMimeData*, QFlags<Qt::MouseButton>, QFlags<Qt::KeyboardModifier>, QFlags<QOpenGLShader::ShaderTypeBit>)’: /var/tmp/portage/dev-python/pyside2-5.15.10/work/pyside-setup-opensource-src-5.15.10/sources/pyside2_build-python3_11/PySide2/QtGui/PySide2/QtGui/qdragmoveevent_wrapper.cpp:103:295: error: invalid user-defined conversion from ‘QFlags<QOpenGLShader::ShaderTypeBit>’ to ‘QEvent::Type’ [-fpermissive] 103 |
Failed to notice package was being built using gcc, not clang. GCC - 12.3.1_p20230526
Confirmed failure is persistent with both llvm/clang and g++.
Build error is referencing QOpenGLShader. Class is apart of dev-qt/qt3d. Enabling pyside2 USE flag "3d", installing dev-qt/qt3d, and rebuilding did not change situation from original observations.
Could you try to rebuild shiboken2? This is always a good first step when pyside2 is not working as it should. Also, pyside2 gets very upset when you try to build it with a different toolchain then shiboken2 was built with. Can you double check that the same toolchain is used for both packages?
(In reply to Andrew Ammerlaan from comment #9) > Could you try to rebuild shiboken2? This is always a good first step when > pyside2 is not working as it should. > > Also, pyside2 gets very upset when you try to build it with a different > toolchain then shiboken2 was built with. Can you double check that the same > toolchain is used for both packages? Effort to rebuild all qt with a single toolchain currently in progress. News to follow...
After toolchain rebuild with llvm/clang 16, problem as originally reported persists.
(In reply to Scott Furry from comment #7) > Confirmed failure is persistent with both llvm/clang and g++. When you tried with clang, did you also recompile shiboken2 with clang? Can you also try without specifying the toolchain tools at all (i.e. unset CC, CXX, etc), this is the configuration that works for me. Pyside is extremely fragile and pyside2 is no longer maintained upstream, all development has moved to pyside6. So it is very difficult to get these issues fixed. If you have the option I recommend using PyQt5 instead, many (but not all) applications allow using either Qt4Python implementation.
(In reply to Andrew Ammerlaan from comment #12) > (In reply to Scott Furry from comment #7) > > Confirmed failure is persistent with both llvm/clang and g++. > > When you tried with clang, did you also recompile shiboken2 with clang? Can > you also try without specifying the toolchain tools at all (i.e. unset CC, > CXX, etc), this is the configuration that works for me. I have rebuilt all with both clang and gcc. There was no change to the output error reported. > > Pyside is extremely fragile and pyside2 is no longer maintained upstream, > all development has moved to pyside6. So it is very difficult to get these > issues fixed. If you have the option I recommend using PyQt5 instead, many > (but not all) applications allow using either Qt4Python implementation. This is the first time I have had any issues in building pyside2. I thought the issue might be related to clang because of different build failure. Unable to confirm. Qt6 - Everybody rushing to next latest thing. No surprise. PyQt5 already installed.
Created attachment 869174 [details] build_log - no CC/CXX
Not specifying CC/CXX leads to other issues. Shiboken will use whatever compiler is first available (normally GCC). However, pyside will attempt to use Clang. End result is aborted build due to... --- /usr/lib/gcc/x86_64-pc-linux-gnu/12/include/g++-v12/cstddef:50:10: fatal: 'stddef.h' file not found --- (see latest "build_log" attachment) Setting shiboken to use Clang (via /etc/package.env) and rebuilding both results in the original problem as reported. This issue didn't exist prior to an upgrade of python-3.11.4 to 3.11.5. Something is broken here. Other distributions have encountered similar situations but in previous versions of pyside2 (5.15.9 or earlier). No clear understanding of problems have been found. A workaround to unclear problems is not possible. My suspicion is that this issue will not be fixed because it relates to Qt 5.15 branch.
Escalating situation. https://bugreports.qt.io/browse/PYSIDE-2451
Answer from Qt: ---- This is an issue caused by clang 16. Also, 5.15.10 only supports Python 3.10. 5.15 standard LTS has expired, though; it will not be adapted to newer versions any more (see https://lists.qt-project.org/pipermail/announce/2023-May/000416.html ). ---- In short, Pyside2 is nearing death. Bereft of updates.("...beautiful plumage the Norwegian Blue..."). Gentoo is reporting that Qt6/Pyside6 has not yet reached normalization. The Qt announcement regarding Qt5 may encourage matters.
(In reply to Scott Furry from comment #17) > Answer from Qt: > ---- > This is an issue caused by clang 16. Also, 5.15.10 only supports Python 3.10. > > 5.15 standard LTS has expired, though; it will not be adapted to newer > versions any more (see > https://lists.qt-project.org/pipermail/announce/2023-May/000416.html ). > ---- Shiboken2 should already be pulling in clang-15. We have a patch for python3.11 compatibility. > In short, Pyside2 is nearing death. Bereft of updates.("...beautiful plumage > the Norwegian Blue..."). > > Gentoo is reporting that Qt6/Pyside6 has not yet reached normalization. The > Qt announcement regarding Qt5 may encourage matters. What exactly is it on your system that is pulling in pyside2? Maybe it is more worthwhile to look into switching this application to pyside6.
And having shiboken2 using python-3.11 is wonderful. However, it is clang-16 that is also a problem for me. Downgrading toolset is not advantageous. Given the software version limits encountered, I will have to reconsider approaches in a piece of software I am maintaining that uses Pyside2. FWIW, I'm having an informative conversation with the folks at Qt in the bug thread above regarding python/llvm/Qt. Seems the migration to latest/greatest is not going exactly "smoothly". A link to a rather handy "compatibility-matrix" for Pyside was provided (https://wiki.qt.io/Qt_for_Python#Python_compatibility_matrix). I'm hopeful they'll shake the bugs out, preferably in an environmentally friendly manner(sans chemicals with minimal carbon-footprint).
