| Summary: | dev-qt/qtdeclarative fails to compile if previous version is installed | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Matthias Dahl <ua_gentoo_bugzilla> |
| Component: | [OLD] Library | Assignee: | Qt Bug Alias <qt> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | ionen, josef64, kkimdavenport, uwelk |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://bugreports.qt-project.org/browse/QTBUG-35619 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | build log w/ qt5-build.eclass fix v1 | ||
|
Description
Matthias Dahl
2014-01-22 08:27:56 UTC
Upstream closed the bug report, saying that this is clearly a problem with packaging. For the record: A similar problem exists at least also for qtwebkit, which can only be compiled successfully if any existing previous < v5.2 has been uninstalled. This is one of the major blockers keeping Qt 5 from portage. Unfortunately we haven't worked out a fix yet. *** This bug has been marked as a duplicate of bug 451456 *** Ah, sorry for the bug spam. I honestly didn't find the already open bug. (In reply to Matthias Dahl from comment #4) > Ah, sorry for the bug spam. I honestly didn't find the already open bug. No problem, as you can see it's a popular bug and it's good to know people are testing even in this state. :-) (Plus that extra include noted in the bug linked here may well be the clue we needed) This is slightly different from bug 451456, which is about undefined references during linking, while this one is about wrong include (-I) order in the compiler command line. The root cause could be the same though. Anyway, I just committed a tentative fix [1] that *might* solve the issue for non-qtbase modules [2]. Can you pull and try the 5.1.x -> 5.2.0 upgrade again please? [1] https://git.overlays.gentoo.org/gitweb/?p=proj/qt.git;a=commitdiff;h=439d470f64b8c05da04c4cb3a6cb2d174cb9e543 [2] Unfortunately we need that export in order to be able to build qtbase modules separately. At this time I have no idea how to solve this *and* still support split ebuilds for qtbase. Sure. I'll try to squeeze it in for sometime today. Even though I don't have 5.1 on the drive anymore, this is quite easy to test imho: I'll just garble all 5.2 include files and re-emerge qt altogether. No qt module should grab something qt related from the system, if its not a dependency that has been compiled and installed before it. Sorry to say but everything compiles up to qtdeclarative w/ the garbled includes but w/ qtdeclarative, it is still the same story: make[2]: Entering directory '/var/tmp/portage/dev-qt/qtdeclarative-5.2.0/work/qtdeclarative-opensource-src-5.2.0_build/tools/qml' x86_64-pc-linux-gnu-g++ -c -march=native -O2 -pipe -std=c++0x -fno-exceptions -Wall -W -D_REENTRANT -fPIE -DQT_NO_XCB -DQT_QML_DEBUG_NO_WARNING -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_QML_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I/usr/lib64/qt5/mkspecs/linux-g++ -I/var/tmp/portage/dev-qt/qtdeclarative-5.2.0/work/qtdeclarative-opensource-src-5.2.0/tools/qml -I/usr/include/qt5 -I/usr/include/qt5/QtWidgets -I/var/tmp/portage/dev-qt/qtdeclarative-5.2.0/work/qtdeclarative-opensource-src-5.2.0/include -I/var/tmp/portage/dev-qt/qtdeclarative-5.2.0/work/qtdeclarative-opensource-src-5.2.0/include/QtQml -I../../include -I../../include/QtQml -I/usr/include/qt5/QtGui -I/usr/include/qt5/QtCore/5.2.0 -I/usr/include/qt5/QtCore/5.2.0/QtCore -I/usr/include/qt5/QtNetwork -I/usr/include/qt5/QtCore -I.moc -I. -o .obj/main.o /var/tmp/portage/dev-qt/qtdeclarative-5.2.0/work/qtdeclarative-opensource-src-5.2.0/tools/qml/main.cpp That -I/usr/include/qt5 is way too high in priority. Does the build actually fail? Or better, can you attach both the old and the new failing build logs? The build failed, just like before. It did quite a bit of debugging w/ the pri files and stuff but so far, I am also empty handed... sorry. I'll attach the build log in a second. It's from the current run w/ your fix. The #error-pragmas are from the live system include files (those that I've changed) that haven't been overwritten yet by successful emerges, thus they shouldn't be included. Created attachment 368570 [details]
build log w/ qt5-build.eclass fix v1
I think the root cause is in this line https://qt.gitorious.org/qt/qtdeclarative/source/e895bc315f9959a5dad80a8f0bf7b73bced0bde1:src/qml/debugger/qqmldebug.h#L45 Ok, I spent a considerable amount of time today on this testing and debugging, hopefully it was worth it somehow because I hit a wall for now. :( The following is purely meant in the context of the qtdeclarative failure, specifically failing on tools/qml: The key clue I discovered: If in the project file (tools/qml/qml.pro) a module is added to the CONFIG variable and that respective module pri file (defined in /usr/lib64/qt5/mkspecs/modules) contains a .depends with any dependency on anything other than core or nothing, the dependency calculation changes wrt to ordering... and thus the global /usr/include/qt5 include path gets a huge boost in priority. Give it a try: Kick gui from .depends in qt_lib_widgets.pri, and qtdeclarative will happily compile and not use anything from the live system it shouldn't. Change the remaining core to sql, and it will fail, even though sql only depends on core. The problem being, again, the include path ordering. Now change it back to just core and add sql to the CONFIG line in qml.pro in tools/qml... it will compile just fine w/ the added include paths and proper ordering. Maybe this is a dead-end but I firmly believe that every clue leads one closer to a solution or the cause. So, maybe this rings a bell for someone else now. For me though, I have seen enough Qt compile msgs rushing by my eyes for a day. ;) Thanks for doing the hard yards on this one. To pick up from where you guys are... If tools/qml/qml.pro is made to use 'quick-private' like so: QT = qml core-private quick-private Then the includes ordering becomes sane and the build completes successfully. (In reply to Rick Harris from comment #15) > If tools/qml/qml.pro is made to use 'quick-private' like so: > QT = qml core-private quick-private > > Then the includes ordering becomes sane and the build completes successfully. This would create a circular dep between the qml and quick modules, so I don't think this solution is "upstreamable" (In reply to Davide Pesavento from comment #16) > This would create a circular dep between the qml and quick modules, so I > don't think this solution is "upstreamable" Hi Davide, upstream already do this. See the output of: ~ # grep -r quick-private qtdeclarative-opensource-src-5.2.1/* | grep "qml " Note to self: qtbase commit daa847afe30ded0b81b7534a969a646e12d8197c might have solved this for 5.4 (In reply to Davide Pesavento from comment #18) > Note to self: qtbase commit daa847afe30ded0b81b7534a969a646e12d8197c might > have solved this for 5.4 Don't think so. Still see this behavior with dev-qt/qtdeclarative-5.3.2 installed and trying to update to 5.4.0 The behavior is still there with the dev-qt/qtdeclarative-5.4.2-r1 to dev-qt/qtdeclarative-5.5.1-r1 upgrade (both marked as stable). I hit the bug too while trying to update from 5.6.2 to 5.7.1 (both stable at the time of writing). I would be nice to have a warning message to do "emerge --unmerge qtdeclarative && emerge -1 qtdeclarative" when you are doing the update. I assume this obsolete and, even if not, qt5 likely does not change enough anymore (forever 5.15.x) to trigger issues even if using some system bits. as far as I see that with the upgrade dev-qt/qtdeclarative-5.4.2-r1 to dev-qt/qtdeclarative-5.5.1-r1 (both marked as stable). however it is outdated qt5 may not change enough anymore (it's forever 5.15.x) to cause problems even when using some system bits. https://eggycargame.io/ |
