qconfig.pri is searched in: /usr/i686-w64-mingw32/sys-root/mingw/mkspecs instead of /usr/i686-w64-mingw32/sys-root/mingw/share/qt4/mkspecs In FindQt4 we have: FIND_PATH(QT_MKSPECS_DIR NAMES qconfig.pri HINTS ${qt_cross_paths} ... where ${qt_cross_paths} is based on ${CMAKE_FIND_ROOT_PATH}: foreach(qt_cross_path ${CMAKE_FIND_ROOT_PATH}) set(qt_cross_paths ${qt_cross_paths} "${qt_cross_path}/mkspecs") endforeach(qt_cross_path) and ${CMAKE_FIND_ROOT_PATH} is set in /usr/share/mingw/Toolchain-mingw32.cmake as: SET(CMAKE_FIND_ROOT_PATH /usr/i686-w64-mingw32/sys-root/mingw) The result is that linking with static Qt libraries may not work, because the logic of what libraries are added depends on qconfig. Workaround is a symlink to mingw/share/qt4/mkspecs in mingw/.
That seems to be an odd/interesting choice in mingw-qt4 packaging to use something like a /usr/i686-w64-mingw32/sys-root/mingw prefix *and* tack on FHS-like paths after it like: share/qt4/... If that is indeed the common/best practice, then FindQt4.cmake indeed needs some love to accomodate that.
The path makes sense to me (we're essentially changing %{_prefix} to /usr/i686-w64-mingw32/sys-root/mingw). Looking at FindQt4 it also does: _qt4_query_qmake(QMAKE_MKSPECS qt_mkspecs_dirs) And looks there as well: find_path(QT_MKSPECS_DIR NAMES qconfig.pri HINTS ${qt_cross_paths} ${qt_mkspecs_dirs} # /usr/bin/i686-w64-mingw32-qmake-qt4 -query QMAKE_MKSPECS /usr/i686-w64-mingw32/sys-root/mingw/share/qt4/mkspecs So why isn't that working? Not querying the correct qmake?
Indeed, wrong qmake is used. In _QT4_QUERY_QMAKE I get -- QT_QMAKE_EXECUTABLE='/bin/qmake-qt4' Toolchain is setting QT_BINARY_DIR, but it seems that FIND_PROGRAM(QT_QMAKE_EXECUTABLE ...) in FindQt is not taking it into account.
When using mingw32-cmake it seems to use qmake-qt4 from: QT_QMAKE_EXECUTABLE=/usr/i686-w64-mingw32/bin/qmake-qt4 Have you tried using that? Do you have a sample CMakeLists.txt for testing?
Toolchain appears to be setting QT_BINARY_DIR to: QT_BINARY_DIR=/usr/i686-w64-mingw32/bin/usr/bin which isn't correct. --- /usr/share/mingw/Toolchain-mingw32.cmake.orig 2012-10-29 20:53:22.038953114 -0600 +++ /usr/share/mingw/Toolchain-mingw32.cmake 2012-10-29 20:52:00.350620208 -0600 @@ -14,7 +14,7 @@ SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) # Make sure Qt can be detected by CMake -SET(QT_BINARY_DIR /usr/i686-w64-mingw32/bin /usr/bin) +SET(QT_BINARY_DIR /usr/i686-w64-mingw32/bin) # set the resource compiler (RHBZ #652435) SET(CMAKE_RC_COMPILER /usr/bin/i686-w64-mingw32-windres) should do the trick.
(In reply to comment #4) > When using mingw32-cmake it seems to use qmake-qt4 from: > > QT_QMAKE_EXECUTABLE=/usr/i686-w64-mingw32/bin/qmake-qt4 I didn't know about mingw32-cmake, I just used plain cmake, like this: cmake -D CMAKE_TOOLCHAIN_FILE=/usr/share/mingw/Toolchain-mingw32.cmake .. It indeed works when calling through mingw32-cmake or when PATH is set as in mingw32-cmake: PATH=/usr/i686-w64-mingw32/bin:$PATH. > > Do you have a sample CMakeLists.txt for testing? cmake_minimum_required(VERSION 2.8) project(foo CXX) set(CMAKE_FIND_LIBRARY_SUFFIXES ${CMAKE_STATIC_LIBRARY_SUFFIX}) find_package(Qt4 REQUIRED QtCore QtGui) include(${QT_USE_FILE}) message(STATUS "QT_QMAKE_EXECUTABLE='${QT_QMAKE_EXECUTABLE}'") I think changing QT_BINARY_DIR (comment 5) doesn't affect qmake path.
It appears it doesn't, must have not removed my cache when testing. So it appears that FindQt4 looks for qmake in $PATH and env $QTDIR/bin. It sets QT_BINARY_DIR from qmake output if not already set, but does not use it to find qmake. If anyone has a good suggestion for how this should be handled in FindQt4, please file a bug upstream. Otherwise I suggest using mingw32-cmake, or setting PATH or QTDIR. I suppose the QT_BINARY_DIR should still be fixed in Toolchain-mingw32.cmake, or perhaps just removed to avoid confusion?
The Fedora MinGW SIG recommends to use the mingw32-cmake / mingw64-cmake wrappers to call CMake with the proper environment set. Internally these wrappers call this RPM macro: %mingw32_cmake %{mingw32_env} ; \ if test -f CMakeLists.txt; then __mingw32_topdir=.; \\\ elif test -f ../CMakeLists.txt; then __mingw32_topdir=..; \\\ else __mingw32_topdir=""; fi; \\\ PATH=%{_prefix}/%{mingw32_target}/bin:$PATH %__cmake \\\ -DCMAKE_VERBOSE_MAKEFILE=ON \\\ -DCMAKE_INSTALL_PREFIX:PATH=%{mingw32_prefix} \\\ -DCMAKE_INSTALL_LIBDIR:PATH=%{mingw32_libdir} \\\ -DINCLUDE_INSTALL_DIR:PATH=%{mingw32_includedir} \\\ -DLIB_INSTALL_DIR:PATH=%{mingw32_libdir} \\\ -DSYSCONF_INSTALL_DIR:PATH=%{mingw32_sysconfdir} \\\ -DSHARE_INSTALL_PREFIX:PATH=%{mingw32_datadir} \\\ %{?_cmake_skip_rpath} \\\ -DBUILD_SHARED_LIBS:BOOL=ON \\\ -DCMAKE_TOOLCHAIN_FILE=/usr/share/mingw/Toolchain-mingw32.cmake \\\ ${MINGW_CMAKE_ARGS} \\\ ${MINGW32_CMAKE_ARGS} \\\ "$@" $__mingw32_topdir If I understand the discussion above correctly then the QT_BINARY_DIR which is set in Toolchain-mingw32.cmake / Toolchain-mingw64.cmake is redundant and should be removed. I just tried to remove it from the toolchain file, but doing so causes mingw32-cmake to not be able to detect to qt tools (like moc and rcc) any more. I think this is because QT_BINARY_DIR will be set to /usr/i686-w64-mingw32/sys-root/mingw/bin internally by CMake. However, this path only contains cross-compiled binaries. The native binaries belonging to the cross-compiled Qt are in /usr/i686-w64-mingw32/bin (we don't want to mix native and cross-compiled binaries in the same folder). In the FindQt4.cmake file there's this snippet of code: # ask qmake for the binary dir IF (NOT QT_BINARY_DIR OR QT_QMAKE_CHANGED) _qt4_query_qmake(QT_INSTALL_BINS qt_bins) SET(QT_BINARY_DIR ${qt_bins} CACHE INTERNAL "" FORCE) ENDIF (NOT QT_BINARY_DIR OR QT_QMAKE_CHANGED) The qmake variable QT_INSTALL_BINS is used by Qt's build system to determine where the (cross-)compiled binaries will be installed. I could try hack up the mingw-qt package so that QT_INSTALL_BINS points to /usr/i686-w64-mingw32/bin instead of /usr/i686-w64-mingw32/sys-root/mingw/bin but that isn't the most elegant solution and I'm not sure what else will break because of this.. All qmake mkspecs profiles contain variables like QMAKE_MOC which points to the full path where the moc binary is installed. Ideally CMake should be able to use these variables instead of only searching for $QT_INSTALL_BINS/moc or $PATH/moc. Unfortunately these value for these variables can't be extracted with 'qmake-qt4 -query' so I guess a different solution should be searched..
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.