qt.shiboken: (core) CLANG builtins includes directory: /usr/lib/clang/11.0.0/include (core) clang_parseTranslationUnit2(0x0, cmd[10]=-isystem/usr/lib/clang/11.0.0/include -fPIC -Wno-constant-logical-operand -std=c++14 -I/var/tmp/portage/dev-python/pyside2-5.15.1/work/pyside-setup-opensource-src-5.15.1/sources/pyside2/PySide2 -I/usr/include/qt5 -I/usr/include/qt5 -I/usr/include/qt5/QtCore -I/usr/lib64/qt5/mkspecs/linux-g++ /var/tmp/portage/dev-python/pyside2-5.15.1/temp/QtCore_global_JRWmqd.hpp) /usr/include/c++/v1/cstddef:44:15: fatal error: 'stddef.h' file not found (core) Errors in /var/tmp/portage/dev-python/pyside2-5.15.1/temp/QtCore_global_JRWmqd.hpp: /usr/include/c++/v1/cstddef:44:15: fatal: 'stddef.h' file not found /var/tmp/portage/dev-python/pyside2-5.15.1/temp/QtCore_global_JRWmqd.hpp:1:10: note: in file included from /var/tmp/portage/dev-python/pyside2-5.15.1/temp/QtCore_global_JRWmqd.hpp:1: ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_developer-libressl-20201008-134631 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-10.2.0 * clang version 11.0.0 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/11/bin /usr/lib/llvm/11 11.0.0 Available Python interpreters, in order of preference: [1] python3.7 [2] python3.9 (fallback) [3] python3.8 (fallback) [4] python3.6 (fallback) [5] python2.7 (fallback) Available Ruby profiles: [1] ruby25 (with Rubygems) [2] ruby26 (with Rubygems) [3] ruby27 (with Rubygems) * Available Rust versions: [1] rust-bin-1.47.0 [2] rust-1.47.0 * The Glorious Glasgow Haskell Compilation System, version 8.8.4 timestamp(s) of HEAD at this tinderbox image: /var/db/repos/gentoo Thu Oct 15 04:05:16 PM UTC 2020 /var/db/repos/libressl Fri Oct 9 07:35:07 PM UTC 2020 emerge -qpvO dev-python/pyside2 [ebuild N ] dev-python/pyside2-5.15.1 USE="gui multimedia network svg widgets xml -3d -charts -concurrent -datavis -designer -gles2-only -help -location -positioning -printsupport -qml -quick -script -scripttools -scxml -sensors -speech -sql -test -testlib -webchannel -webengine -websockets -x11extras -xmlpatterns" PYTHON_TARGETS="python3_7 -python3_6 -python3_8"
Created attachment 665897 [details] emerge-info.txt
Created attachment 665900 [details] dev-python:pyside2-5.15.1:20201015-164049.log
Created attachment 665903 [details] emerge-history.txt
Created attachment 665906 [details] environment
Created attachment 665909 [details] etc.portage.tbz2
Created attachment 665912 [details] logs.tbz2
Created attachment 665915 [details] temp.tbz2
Created attachment 668210 [details] buildlog
Ran into this as well.
Same thing happened when compiling with gcc-10.2
Fixed by forcing dev-python/shiboken2 to be compiled with clang toolkit.
Does this problem still occur? The ebuild appears to have some lines that look a lot like they are a workaround around this issue.
Yes, that's why I CC-ed you — I can't build the new version.
I'm confused, both versions build just fine for me, I didn't have to force clang on shiboken2. It compiled with clang instead of gcc automatically.
It might be due to USE="default-compiler-rt default-libcxx" on clang.
(In reply to Michał Górny from comment #15) > It might be due to USE="default-compiler-rt default-libcxx" on clang. Yes, this appears to be the case, with those flags I can reproduce this issue (CC="gcc" emerge -1 shiboken && emerge -1 pyside2 fails). Without those flags everything works fine, even if I force CC="gcc". I'm not sure what the best course of action is to fix this, we could force CC="clang", but that doesn't really make sense since it actually does compile with CC="gcc", just not if clang has those flags.
I don't get why pyside2 insists on using clang in the first place. This is just asking for trouble.
(In reply to Michał Górny from comment #17) > I don't get why pyside2 insists on using clang in the first place. This is > just asking for trouble. Shiboken2 apparently requires clang at runtime to do its thing, so my guess is that upstream simply assumes that everyone will be building shiboken2/pyside2 with clang as well and therefore doesn't really care about supporting anything other than clang.
I have the same error. I resolve this by forcing both shiboken2 and pyside2 packages to be compiled with clang.
Is this issue still valid for 5.15.5?
