CMake path error in Qt 5.1.1

Bug #1215414 reported by Timo Jyrinki
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
qtbase-opensource-src (Ubuntu)
Fix Released
Critical
Timo Jyrinki

Bug Description

Qt 5.1.1 pre-release gives a path error regarding CMake builds that did not occur with Qt 5.1.0:

---
CMake Error at /usr/lib/x86_64-linux-gnu/cmake/Qt5Core/Qt5CoreConfig.cmake:27 (message):
  The imported target "Qt5::Core" references the file

     "/usr/lib/include/qt5/"

  but this file does not exist. Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

     "/usr/lib/x86_64-linux-gnu/cmake/Qt5Core/Qt5CoreConfig.cmake"

  but not all the files it references.

Call Stack (most recent call first):
  /usr/lib/x86_64-linux-gnu/cmake/Qt5Core/Qt5CoreConfig.cmake:62 (_qt5_Core_check_file_exists)
  CMakeLists.txt:51 (find_package)
---

Testable via ppa:canonical-qt5-edgers/qt5-beta2

Tags: qt5.1
Changed in qtbase-opensource-src (Ubuntu):
importance: Undecided → High
assignee: nobody → Timo Jyrinki (timo-jyrinki)
tags: added: qt5.1
Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

I found https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=929227 which has discussed a related problem before.

The problem replicates in all CMake files, so even if Qt5CoreConfig.cmake is manually added with set(_qt5Core_install_prefix "/usr"), the next one is eg. Qt5Qml. Furthermore hardcoding it to /usr is not probably what's wanted.

In the qtbase code, probably mkspecs/features/cmake_functions.prf is one place to look at.

Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :
Changed in qtbase-opensource-src (Ubuntu):
status: New → In Progress
Revision history for this message
Dmitry Shachnev (mitya57) wrote :

Can it be related to (mis-)applying debian/patches/Dont_check_for_the_existence_of_priv_inc_dirs.patch (I added it in the last merge)?

Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

Dmitry: No, that patch was actually dropped since seemingly it was merged upstream.

I considered it and many other upstream changes, but eventually did not find any single commit to revert to fix the issue. I found the place where it could be fixed, and overrode the upstream logic by setting the qt5_MODULE_install_prefix equal to QT_INSTALL_PREFIX. That's also one of the options in the upstream logic, but somehow something else got selected now in 5.1.1, unlike in 5.1.

This forcing in qtbase seems to address the issue, I've been now rebuilding all the 5.1.1 modules in qt5-beta2 and at least the initial CMake using projects I found failing now all build fine. Let's hope that's all that there is to it.

Changed in qtbase-opensource-src (Ubuntu):
status: In Progress → Fix Committed
Changed in qtbase-opensource-src (Ubuntu):
importance: High → Critical
Revision history for this message
Scott Kitterman (kitterman) wrote :

If this is the same issue I think it is, there's a backport of an upstream fix in Debian already.

Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

Yes, I've replaced my previous patch with the upstream one already, via a resync from Debian.

Changed in qtbase-opensource-src (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.