| Summary: | qt5-build.eclass breaks Qt 5.9.X | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Ghiunhan Mamut <venerix> |
| Component: | Eclasses | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Sync your tree and upgrade world. *** This bug has been marked as a duplicate of bug 646504 *** |
I'm running Gentoo amd64 in which I mix some ~amd64 packages, mostly qt5/kde-frameworks/kde-apps related stuff. So I have a combo of qt5.9.4/frameworks-5.42/apps-17.12.1. Qt5.9.4 hit the tree about a week ago. So I built and installed it. Then I rebuilt all installed kde-frameworks against new qt5, and then I **tried** to rebuild all installed kde-apps against new qt5 and rebuilt frameworks. And the fun begins. Most apps which rely on qt5 will fail to build with exact same error : error: ‘QGraphicsSvgItem’ was not declared in this scope QGraphicsSvgItem *svgItem = new QGraphicsSvgItem(fileName); And to top that, sddm shows a nice black screen of death, even though the logs say greeter started. Quickly disabled sddm, and tried to start the lxqt session from cli, using good old startx. But it failed, apparently cannot find xcb backend. QT_DEBUG_PLUGINS=1 startlxqt shows xcb backend is actually in place, but it cannot be loaded. Installed openbox, fired up a openbox-session. All qt5 apps fail to load with xcb backend missing error. All other apps work. So I fire up xterm and : QT_QPA_PLATFORM=xcb startlxqt ... Evrika ... lxqt session starts and qt5 apps work as well. I place that var in /etc/env.d, run env-update with the hope sddm will fire up as well, but no luck. I realised that exported env var is just a workaround and the actual breakcage is somewhere else. So, let's dig a bit deeper. At first, I thought qt5.9.4 is to blame, so I reverted to qt5.9.3, a version who never caused any issue for me. Rebuilt all installed kde-frameworks against downgraded qt5, and once again I **tried** to rebuild all installed kde-apps against dowgraded qt5. The fun continues, as once again most qt5 apps failed to build with the error above. Sddm kept failing, I had to export that env var again to have something work. I realised something broke the qt5 build entirely. So, let's dig even deeper for missing symbols. I started to randomly fire qt5 apps to get a runtime error. Finally one qt5 app failed with : relocation error: symbol _ZTI16QGraphicsSvgItem, version Qt_5 not defined in file libQt5Svg.so.5 with link time reference Evrika...now it makes sense...they failed to rebuild because of the same missing symbol...Let's check if that symbol is actually exported by libQt5Svg.so.5 strings /usr/lib/libQt5Svg.so.5 | grep _ZTI16QGraphicsSvgItem This returned nothing. Checked on a different machine (out-of-date) : strings /usr/lib/libQt5Svg.so.5 | grep _ZTI16QGraphicsSvgItem This returned _ZTI16QGraphicsSvgItem So, qt5 libraries have missing symbols all over the place, qt5 is totally broken. Let's see what caused this. Looked at portage tree changes. About the same time with qt5.9.4 some changes were pushed into qt5-build.eclass . Reverted them, did my rebuild ritual, and voila ... everything works. Doesn't matter if qt5.9.3 or qt5.9.4 ... everything works ... For the sake of reproducing, I rebuilt one more time with qt5-build.eclass changes in place ... and once again, everything went crazy ... then once again I reverted qt5-ebuild.eclass changes and rebuilt ... and once again, everything works... I know is a very long story, but it took me 3 days of rebuilding, testing, rebuilding, testing, digging deeper and deeper to find this. If more information is required feel free to ask for it.