I created this bug because sys-auth/polkit-qt[qt4] does not build with qtchooser. Tested on the newest stable version (0.112.0-r1). Build fails on configure phase because FindQt4.cmake script cannot find qmake from qt4 (/usr/bin/qmake is symlink to qtchooser, which in turn points to qmake from qt5, and FindQt4.cmake script does not search /usr/lib/qt4/bin for qmake). As this problem is not specific for this single ebuild, my proposition is to add the following symlink (for example in qtcore ebuild): /usr/bin/qmake-qt4 -> /usr/lib/qt4/bin/qmake Similar symlink for qmake from qt5 also could be useful. FindQt4.cmake will try qmake-qt4 if it is present in the path, and build will run successfully. This is how it works in Debian-based distros.
Note: I had the same problem with kde-base/kdelibs. The trick with qmake-qt4 symlink did not work, because kdelibs package has its own copy of FindQt4.cmake file in <src>/cmake/modules directory - probably it is outdated. To build it I had to set qt4 PATH as the default one in qtchooser's default.conf file.
This is a problem in ebuilds that do not use qt4_get_bindir from qmake-utils.eclass to find the right location for qmake. Ebuilds should not be using the qtchooser symlink. Blocking the tracker bug.
This affects most/all cmake-based packages that use Qt4. @qt, any thoughts about solving? We could patch the file, hard-coding the new qmake location, or add additional search locations?
(In reply to Michael Palimaka (kensington) from comment #3) > This affects most/all cmake-based packages that use Qt4. > > @qt, any thoughts about solving? We could patch the file, hard-coding the > new qmake location, or add additional search locations? Hardcoding the new path is ok I think, we're not going to change it again. Ideally the cmake macro should first look in /usr/$(get_libdir)/qt4/bin, and then in /usr/bin as a fallback for people still on 4.8.5. This search logic applies to all Qt4 build tools (moc, uic, lrelease, ...)
Created attachment 414218 [details, diff] cmake-3.3.2-qmake.patch cmake patch to ensure the right qmake is called. Calls to all other tool should be fixed automagically, since they are called after querying QT_INSTALL_* from the found qmake.
(In reply to Michael Palimaka (kensington) from comment #5) > Created attachment 414218 [details, diff] [details, diff] > cmake-3.3.2-qmake.patch If I have multilib qt4 installed for both _32 and _64 ABIs, would this always find the 32 bit version of qmake?
Created attachment 414256 [details, diff] cmake-3.3.2-qmake.patch v2 Thanks Davide. It was pointed out that we unconditionally set some magic variables in the eclass, so this updated patch makes use of them. Tests OK again dev-libs/libdbusmenu-qt.
(In reply to Michael Palimaka (kensington) from comment #7) > Created attachment 414256 [details, diff] [details, diff] > cmake-3.3.2-qmake.patch v2 v2 looks good to me.
Thanks, fixed in git. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0ee1361bd482a7f8fb88b72c8975fdaebc4c4348
