qt.shiboken: (core) CLANG builtins includes directory: /usr/lib/clang/11.0.0/include
(core) clang_parseTranslationUnit2(0x0, cmd=-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)
 x86_64-pc-linux-gnu-10.2.0 *
clang version 11.0.0
Thread model: posix
Available Python interpreters, in order of preference:
 python3.9 (fallback)
 python3.8 (fallback)
 python3.6 (fallback)
 python2.7 (fallback)
Available Ruby profiles:
 ruby25 (with Rubygems)
 ruby26 (with Rubygems)
 ruby27 (with Rubygems) *
Available Rust versions:
 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]
Created attachment 665900 [details]
Created attachment 665903 [details]
Created attachment 665906 [details]
Created attachment 665909 [details]
Created attachment 665912 [details]
Created attachment 665915 [details]
Created attachment 668210 [details]
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?