Closed hedmo closed 4 years ago
Fascinating! We certainly can't have build errors. Thanks for the detailed logfile, @hedmo.
pyside2-5.14.1
successfully compiles on my side, so this could take a bit of grepping. Let's see what dark secrets we unearth from deep within the smelly innards of PySide2's CMakeLists.txt
build system, shall we?
This appears to be the first relevant fatal error – fairly early in the compilation, thankfully:
[18/772] cd /var/tmp/portage/dev-python/pyside2-5.14.1/work/pyside-setup-opensource-src-5.14.1/sources/pyside2/PySide2/QtXml && /usr/bin/shiboken2-python2.7 --generator-set=shiboken --enable-parent-ctor-heuristic --enable-pyside-extensions --enable-return-value-heuristic --use-isnull-as-nb_nonzero /var/tmp/portage/dev-python/pyside2-5.14.1/work/pyside-setup-opensource-src-5.14.1/sources/pyside2-python2_7/PySide2/QtXml_global.h --include-paths=/var/tmp/portage/dev-python/pyside2-5.14.1/work/pyside-setup-opensource-src-5.14.1/sources/pyside2/PySide2:/usr/include/qt5/ --typesystem-paths=/var/tmp/portage/dev-python/pyside2-5.14.1/work/pyside-setup-opensource-src-5.14.1/sources/pyside2-python2_7/PySide2:/var/tmp/portage/dev-python/pyside2-5.14.1/work/pyside-setup-opensource-src-5.14.1/sources/pyside2/PySide2:/var/tmp/portage/dev-python/pyside2-5.14.1/work/pyside-setup-opensource-src-5.14.1/sources/pyside2/PySide2/QtXml --output-directory=/var/tmp/portage/dev-python/pyside2-5.14.1/work/pyside-setup-opensource-src-5.14.1/sources/pyside2-python2_7/PySide2/QtXml --license-file=/var/tmp/portage/dev-python/pyside2-5.14.1/work/pyside-setup-opensource-src-5.14.1/sources/pyside2/PySide2/QtXml/../licensecomment.txt /var/tmp/portage/dev-python/pyside2-5.14.1/work/pyside-setup-opensource-src-5.14.1/sources/pyside2/PySide2/QtXml/typesystem_xml.xml --api-version=5.14 --drop-type-entries=""
FAILED: PySide2/QtXml/mjb_rejected_classes.log PySide2/QtXml/PySide2/QtXml/qdomattr_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qdomcdatasection_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qdomcharacterdata_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qdomcomment_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qdomdocument_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qdomdocumentfragment_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qdomdocumenttype_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qdomelement_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qdomentity_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qdomentityreference_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qdomimplementation_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qdomnamednodemap_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qdomnode_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qdomnodelist_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qdomnotation_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qdomprocessinginstruction_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qdomtext_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qxmlattributes_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qxmlcontenthandler_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qxmldeclhandler_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qxmldefaulthandler_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qxmldtdhandler_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qxmlentityresolver_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qxmlerrorhandler_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qxmlinputsource_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qxmllexicalhandler_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qxmllocator_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qxmlnamespacesupport_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qxmlparseexception_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qxmlreader_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qxmlsimplereader_wrapper.cpp PySide2/QtXml/PySide2/QtXml/qtxml_module_wrapper.cpp
cd /var/tmp/portage/dev-python/pyside2-5.14.1/work/pyside-setup-opensource-src-5.14.1/sources/pyside2/PySide2/QtXml && /usr/bin/shiboken2-python2.7 --generator-set=shiboken --enable-parent-ctor-heuristic --enable-pyside-extensions --enable-return-value-heuristic --use-isnull-as-nb_nonzero /var/tmp/portage/dev-python/pyside2-5.14.1/work/pyside-setup-opensource-src-5.14.1/sources/pyside2-python2_7/PySide2/QtXml_global.h --include-paths=/var/tmp/portage/dev-python/pyside2-5.14.1/work/pyside-setup-opensource-src-5.14.1/sources/pyside2/PySide2:/usr/include/qt5/ --typesystem-paths=/var/tmp/portage/dev-python/pyside2-5.14.1/work/pyside-setup-opensource-src-5.14.1/sources/pyside2-python2_7/PySide2:/var/tmp/portage/dev-python/pyside2-5.14.1/work/pyside-setup-opensource-src-5.14.1/sources/pyside2/PySide2:/var/tmp/portage/dev-python/pyside2-5.14.1/work/pyside-setup-opensource-src-5.14.1/sources/pyside2/PySide2/QtXml --output-directory=/var/tmp/portage/dev-python/pyside2-5.14.1/work/pyside-setup-opensource-src-5.14.1/sources/pyside2-python2_7/PySide2/QtXml --license-file=/var/tmp/portage/dev-python/pyside2-5.14.1/work/pyside-setup-opensource-src-5.14.1/sources/pyside2/PySide2/QtXml/../licensecomment.txt /var/tmp/portage/dev-python/pyside2-5.14.1/work/pyside-setup-opensource-src-5.14.1/sources/pyside2/PySide2/QtXml/typesystem_xml.xml --api-version=5.14 --drop-type-entries=""
qt.shiboken: (xml) Unable to locate Clang's built-in include directory (neither by checking the environment variables LLVM_INSTALL_DIR, CLANG_INSTALL_DIR nor running llvm-config). This may lead to parse errors.
(xml) clang_parseTranslationUnit2(0x0, cmd[6]=-fPIC -Wno-constant-logical-operand -std=c++14 -I/var/tmp/portage/dev-python/pyside2-5.14.1/work/pyside-setup-opensource-src-5.14.1/sources/pyside2/PySide2 -I/usr/include/qt5 /var/tmp/portage/dev-python/pyside2-5.14.1/temp/QtXml_global_tEniZu.hpp)
/usr/lib/gcc/x86_64-pc-linux-gnu/10.0.1/include/g++-v10/cstddef:50:10: fatal error: 'stddef.h' file not found
(xml) Errors in /var/tmp/portage/dev-python/pyside2-5.14.1/temp/QtXml_global_tEniZu.hpp:
/usr/lib/gcc/x86_64-pc-linux-gnu/10.0.1/include/g++-v10/cstddef:50:10: fatal: 'stddef.h' file not found
/var/tmp/portage/dev-python/pyside2-5.14.1/temp/QtXml_global_tEniZu.hpp:1:10: note: in file included from /var/tmp/portage/dev-python/pyside2-5.14.1/temp/QtXml_global_tEniZu.hpp:1:
/var/tmp/portage/dev-python/pyside2-5.14.1/work/pyside-setup-opensource-src-5.14.1/sources/pyside2-python2_7/PySide2/QtXml_global.h:41:10: note: in file included from /var/tmp/portage/dev-python/pyside2-5.14.1/work/pyside-setup-opensource-src-5.14.1/sources/pyside2-python2_7/PySide2/QtXml_global.h:41:
/usr/include/qt5/QtCore/qnamespace.h:43:10: note: in file included from /usr/include/qt5/QtCore/qnamespace.h:43:
/usr/include/qt5/QtCore/qglobal.h:46:12: note: in file included from /usr/include/qt5/QtCore/qglobal.h:46:
:0: error: Unable to retrieve code snippet. [other]
Given this, it would seem the obsolete Python 2.7 version of Shiboken2 is unable to find Clang when generating bindings for the obsolete Python 2.7 version of PySide2. Let's see whether this also applies to Python >= 3.6 as well, shall we?
@hedmo: Would you mind manually reinstalling dev-python/shiboken2
for us and trying again: e.g.,
$ emerge dev-python/shiboken2 dev-python/pyside2
Your current Shiboken2 installation appears to be fundamentally broken. This shouldn't happen, of course. I'll continue grepping around, but... I'm afraid I didn't find much of relevance. "Curse these sausage fingers of mine!"
Ultimately, I may need to refactor the Shiboken2 ebuild to find Clang more portably. The current approach is possibly less than ideal. </sigh>
@leycec thank you for THE fast reply.i am om a quite bleeding edge system (gcc-10 and llvm/clang-11). gcc is My compiler. i am on My way to work now but getting to My box in 10h.but post what you need me to do and i am on it after work.
Regards
Edit: @leycec i dont think dev-python/shiboken2 has been pulled in but i check.
Thank you for keeping up with me! :running_man:
i am om a quite bleeding edge system (gcc-10 and llvm/clang-11). gcc is My compiler.
Right. I noticed that you're compiling under GCC 10.0.1, which I have sadly yet to test. I'm only on GCC 9.2.0 and Clang 9.0.1 myself, 'cause bleeding-edge C++ compilers frighten me like skittish schoolgirls on prom night.
Untested compiler versions could be the issue, but... this intuitively feels like something simpler. Regardless of GCC or Clang version, Shiboken2 should always be able to find Clang – because we force it to.
Edit: @leycec i dont think
dev-python/shiboken2
has been pulled in but i check.
dev-python/shiboken2
should definitely have already been pulled in. If you could verify that, that'd be swell. For my part, I'll keep grepping around and see if I can come up with any forbidden black magic here.
Ugh. On the bright side, I've now added Vulkan support to both Shiboken2 and PySide2. Yay. On the dark side, that has nothing whatsoever to do with this issue. Boo.
I'm honestly stumped. After core-dumping several hours into the ugly guts of Clang, CMake, and the unified build system for Shiboken2 and PySide2, I'm no closer to solving this for you. This could very well be an issue with untested versions of GCC and Clang after all. Unfortunately, these versions are currently hard-masked; for my own personal sanity and safety, I'd rather eviscerate myself with a rusty razor than locally install hard-masked C++ compilers.
With sincere apologies, I probably won't be able to resolve this until GCC 10 and Clang 11 stabilize up. I hate leaving critical issues unresolved, but... here we are. :anger:
Oh, and one last thing: would you mind posting your Shiboken2 build log when you rebuild dev-python/shiboken2
? I'm mildly curious to see where Shiboken2 detects your Clang installation as living.
@leycec i am going start with downgrading llvm/clang and start compiling pyside2 and Shiboken2b after i have checked if Shiboken2 is in My system.
Awesome! Thanks so much for the Shiboken2 logfile. I must admit that everything looks superficially fine: Shiboken2 successfully finds Clang 11 when compiled against GCC 10 under both Python 2.7 and 3.6.
Let's let this percolate in my brainpan. Maybe I can still come up with a surprise victory.
Good morning from My side.yes Shiboken2 was compiling Fine.i am revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc att the moment to sort out LTO linking errors as i recompile gcc quite often. Giving you more feedbacks after work.
Regards
Thanks a bunch, @hedmo. And thanks for voluntarily downgrading gcc and Clang for us. I know what a heavy timesink that must be – even if your superhuman machine does have 40 cores and/or hyperthreads, which is just cray-cray.
My geriatric machine is heroically limping along with only two cores... hides face in shame forever
@leycec lol...my machine is just an area51m with a i7 9700 in it so yes it will take some time to figure this one out. future is future and this is how it has to be done to pin out the main fault .now i am on the first main release LLVM 10.0.0 and it is still failing : pyside2.log downgrading gcc at the moment and getting back when it is done .
Yikes. I'm upgrading to unstable LLVM and Clang 10.0.0 as we speak. If I can replicate this, I can solve this. Wish my decrepit machine luck! I'm heading into the compilation hole, folks. :hole:
i have to put my money on LLVM at the moment. pyside2.log
@leycec cstddef is located in : /usr/lib/gcc/x86_64-pc-linux-gnu/10.0.1/include/ and a workaround
was to :
ln -s /usr/lib/gcc/x86_64-pc-linux-gnu/10.0.1/include/stddef.h /usr/lib/gcc/x86_64-pc-linux-gnu/10.0.1/include/g++-v10
but i got a new error.... pyside2.log
@leycec after the workaround i can confirm that the main problem is LLVM-10 and 11. pyside2 is compiling fine with LLVM-9.and as i have manage to understand it is that shiboken2 and pyside2 does not find the clang headers.
regards
Awesomeness. We'll leave this open for... obvious reasons. I'll also explicitly mark the PySide2 and Shiboken2 ebuilds as incompatible with Clang >= 10 to prevent others from stumbling over this miserable roadblock.
Sadly, I couldn't even bump LLVM and Clang to 10.0.0; unstable dependencies appear to be incompatible with gcc >= 9.0.0, which is kinda ludicrous. sys-libs/libomp-10.0.0
fails with the following, for example:
In file included from /opt/cuda/include/cuda_runtime.h:83,
from <command-line>:
/opt/cuda/include/crt/host_config.h:129:2: error: #error -- unsupported GNU version! gcc versions later than 8 are not supported!
129 | #error -- unsupported GNU version! gcc versions later than 8 are not supported!
| ^~~~~
CMake Error at omptarget-nvptx_generated_cancel.cu.o.RelWithDebInfo.cmake:215 (message):
Error generating
/var/tmp/portage/sys-libs/libomp-10.0.0/work/openmp-abi_x86_64.amd64/libomptarget/deviceRTLs/nvptx/CMakeFiles/omptarget-nvptx.dir/__/common/src/./omptarget-nvptx_generated_cancel.cu.o
shaking my bald head
Temporarily "done." Shiboken2 5.14.1 now hard-blocks Clang >= 10.0.0. This is obviously awful, so we'll hopefully remove this on the next Shiboken2 bump after Clang >= 10.0.0 stabilizes a bit and becomes installable for me.
Thanks again for all the tremendous volunteerism, @hedmo! :tada:
Stable qtgui & qtcore switched gles2 to gles2-only within the last 24hrs. Hopefully patched accordingly: pyside2-5.14.1-r11.ebuild.gz
Unfortunately many packages haven't switched accordingly, so whole rebuild remains impossible for now.
Gentoo forum link: https://forums.gentoo.org/viewtopic-t-1110858-start-0-postdays-0-postorder-asc-highlight-.html
Thks 4 ur attention, interest & support
@CaptainBloodz
man you are fast :). thanks a million.your change worked for me.
regards
man you are fast :). thanks a million.your change worked for me.
regards
Most of the work is Gentoo dev 'Andreas Sturmlechner''s aka 'asturm' on the forum.
Side note: expect uptream to have it's own way when upgrading, at least for ebuild name. I generally choose an unrealistic name, expected not to conflict with later upstream according upgrade. There may be a better way to do it, though, as this might seem silly.
Thks 4 ur attention, interest & support.
I doubt the dependency is correct though. The use flag does not tick any build system box and seems to entirely depend on the state of gles2-only use flag in dev-qt/qtgui. Then it should probably be dev-qt/qtgui[gles2-only=] instead.
reported a bug for it : https://bugreports.qt.io/browse/PYSIDE-1261
@leycec here is a fix for building them if you like to: dev-python.zip
erratum: I didn't pay enough attention to @hedmo comments before replying here. patching compilersupport.cpp seems to be a better way of temporary "fixing" the issue... just disregard what I said below ;)
I'm hitting the same issue as mentioned earlier (shiboken not finding the expected system include files).
one way to fix it seem to provide those paths to shiboken? I made a quick change (and quite dirty?) to the pyside CMakeLists.txt to add the -isystem argument in the GENERATOR_EXTRA_FLAGS ... and problem solved?
could be a temporary fix for the impatients like me while waiting for https://codereview.qt-project.org/c/pyside/pyside-setup/+/296271 to land in a proper release? at least, it's how I compiled pyside2 and running freecad right now :)
Brilliant, all. I just noticed this vigorous discussion... and am delighted! Finally, a band of merry weekend warriors to solve all my shameful bugs. I'll deeply inspect the discussion above and (hopefully) come up with a working revision tomorrow that satisfies everyone, solves everything, and shines a PySide2-based light into the dark corners of this world. :couch_and_lamp:
For collective sanity, let's continue the gles2-only
discussion at #84. Thanks for creating that dedicated issue, @clytle374! Man, my users sure rock. :guitar:
OMG. I simply cannot believe shiboken2 naively parsed only the first digit of the Clang version from the Clang includes directory. I mean, I can believe it, but... I don't want to. This is a Picard facepalm for the modern Qt 5.x era.
I speadread compilersupport.cpp
and sadly missed that special insanity. Thanks a million Swedish kronor, @hedmo, for catching that and posting a working changeset. We'll get this merged in posthaste!
hi
i am trying to compile dev-python/pyside2-5.14.1 but it is failing. pyside2.log
regards