New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

qt5: cmake find_package(Qt5Core) doesn't work when linked to /usr/local #8392

Closed
scpeters opened this Issue Jan 2, 2017 · 19 comments

Comments

Projects
None yet
5 participants
@scpeters
Contributor

scpeters commented Jan 2, 2017

Please follow the general troubleshooting steps first:

  • Ran brew update and retried your prior step?
  • Ran brew doctor, fixed as many issues as possible and retried your prior step?
  • Confirmed this is problem with specific formulae and not Homebrew/brew? If it's a general Homebrew/brew problem please file this issue at https://github.com/Homebrew/brew/issues/new

Bug reports:

I have a 3rd-party package that uses cmake to find qt5 with a find_package(Qt5Core) call. The find_package call works if the CMAKE_PREFIX_PATH is set to /usr/local/opt/qt5 but fails if CMAKE_PREFIX_PATH is set to /usr/local with the following console output:

cmake ..
-- The C compiler identification is AppleClang 7.0.2.7000181
-- The CXX compiler identification is AppleClang 7.0.2.7000181
-- Check for working C compiler: /usr/local/opt/ccache/libexec/cc
-- Check for working C compiler: /usr/local/opt/ccache/libexec/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/local/opt/ccache/libexec/c++
-- Check for working CXX compiler: /usr/local/opt/ccache/libexec/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at /usr/local/lib/cmake/Qt5Core/Qt5CoreConfig.cmake:15 (message):
  The imported target "Qt5::Core" references the file

     "/usr/local/.//mkspecs/macx-clang"

  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/local/lib/cmake/Qt5Core/Qt5CoreConfigExtras.cmake"

  but not all the files it references.

Call Stack (most recent call first):
  /usr/local/lib/cmake/Qt5Core/Qt5CoreConfigExtras.cmake:50 (_qt5_Core_check_file_exists)
  /usr/local/lib/cmake/Qt5Core/Qt5CoreConfig.cmake:141 (include)
  CMakeLists.txt:2 (find_package)


-- Configuring incomplete, errors occurred!
See also build/CMakeFiles/CMakeOutput.log".

The following is a sufficient CMakeLists.txt to reproduce the issue:

cmake_minimum_required(VERSION 2.8 FATAL_ERROR)
find_package (Qt5Core)

I only noticed this recently since qt5 was promoted from keg_only. I investigated the error messages, and noticed that qt5 has a mkspecs folder in its Cellar that is not linked into /usr/local/mkspecs. This causes a problem with the find_package call since it tries to find the mkspecs folder relative to where the cmake config file is found, but that folder isn't in /usr/local/mkspecs.

I expect that we won't be linking the mkspecs folder to /usr/local any time soon. As an alternative, I have a patch for qt5 that forces the cmake config files to use an absolute path to the mkspecs folder:

I don't expect this patch would be accepted upstream, since the problem comes from brew's linking to /usr/local. Should I submit a pull request to add the patch to the qt5 formula?

@MikeMcQuaid

This comment has been minimized.

Member

MikeMcQuaid commented Jan 2, 2017

Great work here.

I don't expect this patch would be accepted upstream, since the problem comes from brew's linking to /usr/local. Should I submit a pull request to add the patch to the qt5 formula?

We should definitely submit this upstream; we don't like having any patches that we haven't at least tried to submit upstream. Could you do that and create a PR linking to the upstream patch submission? @steveire may have thoughts/help here.

@ilovezfs

This comment has been minimized.

Contributor

ilovezfs commented Jan 2, 2017

I don't expect this patch would be accepted upstream

I don't see why not if it doesn't break anything else.

@ilovezfs

This comment has been minimized.

@steveire

This comment has been minimized.

steveire commented Jan 2, 2017

This is Homebrew/legacy-homebrew#29938 btw, and you can hit similar issues with any package which installs cmake config files and references paths which are not part of your symlink system.

The upstream Qt files should keep relative paths, so you will have to do patching on the homebrew side to make them absolute.

@ilovezfs

This comment has been minimized.

Contributor

ilovezfs commented Jan 2, 2017

The upstream Qt files should keep relative paths

why?

@steveire

This comment has been minimized.

steveire commented Jan 2, 2017

The upstream Qt binary distribution installer asks the user to specify an install location. The installation infrastructure should not have to rewrite those files for example. Relative paths allow avoiding a host of issues like that.

@ilovezfs

This comment has been minimized.

Contributor

ilovezfs commented Jan 2, 2017

Well that's a bit of a mess, then, because we're not going to want to patch it forever. So permanent keg_only status sounds likely since a top level mkspecs folder just for Qt would be goofy.

@steveire

This comment has been minimized.

steveire commented Jan 2, 2017

The mkspecs folder needs to be specified only for a single header file (qplatformdefs.h). If upstream Qt changes to install that file in include/QtCore or so, then the mkspecs path would not need to be in the cmake config files at all. Perhaps that is a goal for you to work towards with upstream Qt.

@ilovezfs

This comment has been minimized.

Contributor

ilovezfs commented Jan 2, 2017

Aren't we going to have this same problem with the other Qt-specific folders installed directly into the prefix?

/usr/local/Cellar/qt5/5.7.1/doc: directory
/usr/local/Cellar/qt5/5.7.1/mkspecs: directory
/usr/local/Cellar/qt5/5.7.1/phrasebooks: directory
/usr/local/Cellar/qt5/5.7.1/plugins: directory
/usr/local/Cellar/qt5/5.7.1/qml: directory
/usr/local/Cellar/qt5/5.7.1/translations: directory
@steveire

This comment has been minimized.

steveire commented Jan 2, 2017

Of the rest, the cmake config files additionally look for content in the plugins directory currently too, but it does so by globbing. I suppose that globbing will simply not find the plugins when using homebrew, so some features might not work with homebrew and that might break a cross-platform experience of some users. That's a lesser impact than the mkspecs issue though I think.

I could imagine the files potentially looking for docs and translations some day too if that would help users make their own docs which link to Qt docs, or re-use Qt translations etc. However, no one is working on that. It's something unlikely to happen, but would be accepted upstream if someone contributed it some day.

@ilovezfs

This comment has been minimized.

Contributor

ilovezfs commented Jan 2, 2017

some features might not work with homebrew and that might break a cross-platform experience of some users

Yeah, that's not good if it was previously working properly when qt5 was keg_only. It sounds like ideally (for us) upstream would have plugins in lib/plugins or share/qt/plugins, or something like that, following FHS.

Immediately, it seems like we have a few choices:

  1. patch qt so mkspecs and plugins can be found by absolute path
  2. revert to keg_only
  3. create new top level directories in /usr/local named mkspecs and plugins (this is problematic because we've been encouraging users to set ownership root:wheel on /usr/local, which means any new top-level folders will require an act of Congress)
  4. watch the 💥 play out and do nothing
@MikeMcQuaid

This comment has been minimized.

Member

MikeMcQuaid commented Jan 2, 2017

@steveire Unlike other package managers we like to get our patches upstream rather than keep them around indefinitely. Would it be possible for us to get something upstream that does uses a realpath equivalent on the relative paths to address this issue?

@MikeMcQuaid

This comment has been minimized.

Member

MikeMcQuaid commented Jan 2, 2017

@steveire If that patch should be in CMake itself we could consider that too.

This was referenced Jan 2, 2017

@MikeMcQuaid

This comment has been minimized.

Member

MikeMcQuaid commented Jan 2, 2017

Have opened #8408 as a temporary workaround.

BrewTestBot added a commit to BrewTestBot/homebrew-core that referenced this issue Jan 2, 2017

qt5: make keg-only again.
Temporarily workaround for Homebrew#8392 until we can get an upstream-suitable
patch.

MikeMcQuaid added a commit that referenced this issue Jan 2, 2017

qt5: make keg-only again.
Temporarily workaround for #8392 until we can get an upstream-suitable
patch.

Closes #8408.

Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>

@rickrankin rickrankin referenced this issue Jan 3, 2017

Closed

"brew install doxygen --with-qt5" fails #8446

3 of 3 tasks complete
@scpeters

This comment has been minimized.

Contributor

scpeters commented Jan 5, 2017

@steveire thanks for the pointer to Homebrew/legacy-homebrew#29938

I noticed there was a cmake bug filed, but it doesn't look like it has seen any action:

@stale

This comment has been minimized.

stale bot commented May 6, 2017

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

@ilovezfs

This comment has been minimized.

Contributor

ilovezfs commented May 7, 2017

Closing this since we have an effective workaround in #8408 but we'd look at a PR with a better fix if it's been upstreamed.

@ilovezfs ilovezfs closed this May 7, 2017

@stale stale bot removed the stale label May 7, 2017

@Lekensteyn

This comment has been minimized.

Contributor

Lekensteyn commented Aug 27, 2017

For downstream users: brew install <package-using-qt5> works with CMake because something sets CMAKE_PREFIX_PATH. To make CMake recognize Qt5 outside brew, add this to CMakeLists.txt before any find_package(Qt5...) call:

if(APPLE AND EXISTS /usr/local/opt/qt5)
	# Homebrew installs Qt5 (up to at least 5.9.1) in
	# /usr/local/qt5, ensure it can be found by CMake since
	# it is not in the default /usr/local prefix.
	list(APPEND CMAKE_PREFIX_PATH "/usr/local/opt/qt5")
endif()

wireshark-gerrit pushed a commit to wireshark/wireshark that referenced this issue Sep 21, 2017

cmake: look for Qt5 from Homebrew on macOS
When Qt5 is installed using Homebrew on macOS, Qt5 is not available in
the default prefix. Remove the hack from macos-setup-brew.sh and adjust
the search path instead. Note that is needed for development, "brew
install" has already set this option in the environment.

See Homebrew/homebrew-core#8392

Change-Id: I57ea09b649a94c9a4cb18b1b2d334808e47ec27e
Reviewed-on: https://code.wireshark.org/review/23232
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>

scpeters added a commit to scpeters/qtbase that referenced this issue Oct 5, 2017

corelib.pro: use absolute install path
This helps for homebrew users who try to `find_package(Qt5Core)`
but can't find the mkspecs folder in `/usr/local`
Homebrew/homebrew-core#8392
@scpeters

This comment has been minimized.

Contributor

scpeters commented Oct 5, 2017

I just submitted a variant of my patch upstream in qt/qtbase#15 and am asking if they can expose a build option that we could invoke from the qt build formula to use absolute paths instead of relative paths. Fingers crossed...

@Homebrew Homebrew locked and limited conversation to collaborators May 4, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.