Created attachment 873191 [details] build log Hello, I am getting this kind of linker errors: /usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libQt6Core5Compat.so.6.5.3: undefined reference to `QUtf8::convertToUnicode(QChar*, QByteArrayView)@Qt_6_PRIVATE_API' Thanks!
Created attachment 873192 [details] emerge --pqv
Created attachment 873193 [details] emerge --info
Can't reproduce. As far as I can see that should be unconditionally defined by libQt6Core.so.6, and libQt6Core5Compat.so.6 is always linked with it. $ nm -DC /usr/lib64/libQt6Core.so.6 | grep "QUtf8::convertToUnicode" 00000000001f3060 T QUtf8::convertToUnicode(QByteArrayView, QStringConverterBase::State*)@@Qt_6_PRIVATE_API 00000000001f03b0 T QUtf8::convertToUnicode(char16_t*, QByteArrayView)@@Qt_6_PRIVATE_API (QChar is char16_t) Giving the impression your qt libraries are broken for some reason.
(In reply to Ionen Wolkens from comment #3) > Giving the impression your qt libraries are broken for some reason. Actually, why is it using libQt6Core5Compat.so.6.5.3 when in the build.log I see e.g. "/usr/lib64/libQt6Core.so.6.6.0 &&" Did portage schedule qtcreator before qt5compat update?
(In reply to Ionen Wolkens from comment #4) > (In reply to Ionen Wolkens from comment #3) > > Giving the impression your qt libraries are broken for some reason. > Actually, why is it using libQt6Core5Compat.so.6.5.3 when in the build.log I > see e.g. "/usr/lib64/libQt6Core.so.6.6.0 &&" > > Did portage schedule qtcreator before qt5compat update? Technically qt-creator does not care which version, but old qt5compat depends on exact versions. Does portage actually need binding operators to resolve this? (like qt5 does, but qt6 never got them -- technically it shouldn't matter given it's pinned to exact version either way). Or did something odd happen here, like an incomplete update.
I did an overnight update to my computer and I actually did not check if everything went well. Thanks for the lead, I just another world update to see what was left [ebuild U ] dev-ruby/irb-1.8.3::gentoo [ebuild U ] sys-libs/compiler-rt-17.0.3:17::gentoo [ebuild U ] sys-libs/compiler-rt-sanitizers-17.0.3:17::gentoo [ebuild U ] sys-devel/clang-runtime-17.0.3:17::gentoo [ebuild U ] sys-libs/libcxxabi-17.0.3::gentoo [ebuild U ] sys-libs/libcxx-17.0.3::gentoo [ebuild U ] dev-qt/qtbase-6.6.0-r1:6/6.6.0::gentoo [ebuild U ] dev-qt/qttools-6.6.0:6/6.6.0::gentoo [ebuild U ] dev-qt/qttranslations-6.6.0:6/6.6.0::gentoo [ebuild U ] dev-qt/qtsvg-6.6.0-r1:6/6.6.0::gentoo [ebuild U ] dev-qt/qt5compat-6.6.0:6/6.6.0::gentoo [ebuild U ] dev-qt/qtimageformats-6.6.0:6/6.6.0::gentoo [ebuild rR ] dev-qt/qt-creator-11.0.3::gentoo [ebuild U ] media-sound/helvum-0.5.1-r1::gentoo [ebuild U ] games-util/lutris-0.5.14::gentoo Yeah so it looks like a partial upgrade, but isn't Qt Creator supposed to pull the updates anyway ?
qt-creator does not depend on a specific version of qt5compat and wouldn't request the upgrade by itself, and I don't think portage checks if revdeps are in a broken state by default (I think it does with --complete-graph or so, but didn't really experiment). At least that ordering looks fine and it should build fine if these updates are done, so guess I'll close this.
Thanks and sorry for the noise !
