Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 498894 - dev-qt/qtdeclarative fails to compile if previous version is installed
Summary: dev-qt/qtdeclarative fails to compile if previous version is installed
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Qt Bug Alias
URL: https://bugreports.qt-project.org/bro...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-22 08:27 UTC by Matthias Dahl
Modified: 2017-10-08 09:54 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build log w/ qt5-build.eclass fix v1 (with-fix-build.log.bz2,24.62 KB, application/x-bzip2)
2014-01-23 16:51 UTC, Matthias Dahl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Dahl 2014-01-22 08:27:56 UTC
If an earlier version of qtdeclarative is installed (5.1.x), qtdeclarative will fail to compile in tools/qml, complaining that RegisterCompositeSingletonType is not part of QQmlPrivate (which is defined in qqmlprivate.h).

The failure comes from the fact that the system-wide qt5 include directory is very high up in the argument list, thus g++ picks up the wrong headers (5.1.x in this case) where RegisterCompositeSingletonType was indeed not yet available.

The URL attached to this bug is the upstream bug report. What remains to be cleared up though is, who is responsible for this bug.

Reproducible: Always
Comment 1 Matthias Dahl 2014-01-22 08:33:49 UTC
Upstream closed the bug report, saying that this is clearly a problem with packaging.
Comment 2 Matthias Dahl 2014-01-22 10:21:05 UTC
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.
Comment 3 Michael Palimaka (kensington) gentoo-dev 2014-01-22 14:54:54 UTC
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 ***
Comment 4 Matthias Dahl 2014-01-22 15:17:47 UTC
Ah, sorry for the bug spam. I honestly didn't find the already open bug.
Comment 5 Michael Palimaka (kensington) gentoo-dev 2014-01-22 15:22:18 UTC
(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)
Comment 6 Davide Pesavento gentoo-dev 2014-01-22 18:01:16 UTC
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.
Comment 7 Matthias Dahl 2014-01-23 09:54:55 UTC
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.
Comment 8 Matthias Dahl 2014-01-23 10:35:49 UTC
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.
Comment 9 Davide Pesavento gentoo-dev 2014-01-23 15:10:47 UTC
Does the build actually fail?
Comment 10 Davide Pesavento gentoo-dev 2014-01-23 15:12:39 UTC
Or better, can you attach both the old and the new failing build logs?
Comment 11 Matthias Dahl 2014-01-23 16:50:34 UTC
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.
Comment 12 Matthias Dahl 2014-01-23 16:51:54 UTC
Created attachment 368570 [details]
build log w/ qt5-build.eclass fix v1
Comment 14 Matthias Dahl 2014-01-24 15:38:11 UTC
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. ;)
Comment 15 Rick Harris 2014-03-12 08:13:29 UTC
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.
Comment 16 Davide Pesavento gentoo-dev 2014-03-12 08:39:17 UTC
(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"
Comment 17 Rick Harris 2014-03-12 22:46:57 UTC
(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 "
Comment 18 Davide Pesavento gentoo-dev 2014-08-24 22:54:14 UTC
Note to self: qtbase commit daa847afe30ded0b81b7534a969a646e12d8197c might have solved this for 5.4
Comment 19 Johannes Hirte 2014-12-23 18:17:04 UTC
(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
Comment 20 Lori 2016-03-17 10:42:43 UTC
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).
Comment 21 René Rhéaume 2017-10-08 00:18:03 UTC
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.