View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0010823CMakeModulespublic2010-06-12 18:092010-12-14 18:50
Reporterhippo 
Assigned ToClinton Stimpson 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionFixed in Version 
Summary0010823: FindQt4.cmake behaves badly in cross-compilation environments.
DescriptionThis bug is created after discussion [1] at mailing list.

Currently, I'm using some hand-written cross-compilation environment, mostly resembling buildroot.
It consists of:
1) host system with general native libraries and utilities;
2) cross-compiled libraries and executables for target system placed at some prefix;
3) special tools, required for cross-compilation and related stuff (cross-toolchain, qmake, image/firmware generators go here).

Tools at item 3) usually must match specific requirements on version used.
In case of Qt, I have statically compiled qmake, moc, uic, lrelease, etc against exactly the same version of Qt used for target system.

If no special care is taken, FindQt4 finds qmake from host system that returns information about host library ignoring CMAKE_FIND_ROOT_PATH (and that's wrong).
If PATH variable is modified appropriately, FindQt4 finds specially compiled qmake with good version.
It's possible to compile qmake to return information, suitable for cross-compilation.
But it's then required to recompile qmake if you change prefix somewhere.

> This can be done by
> - setting CMAKE_PREFIX_PATH so that it points to the base directory where that
> qmake is installed
> - setting QT_QMAKE_EXECUTABLE directly when running cmake:
> cmake -DQT_QMAKE_EXECUTABLE=/your/qmake
I simply modify PATH variable as it works both for qmake and other tools.
I don't like touching CMAKE_PREFIX_PATH, because then cmake will attempt to look for libraries in "${CMAKE_PREFIX_PATH}/lib" and can pick up libraries, compiled for host system.
Also, I'm not sure, how well CMAKE_PREFIX_PATH would work together with CMAKE_FIND_ROOT_PATH.

> How far do you get with this ?
1) FindQt4 finds my qmake
2) FindQt4 runs "qmake -query" or "qmake CMakeTmpQmake/tmp.pro"
3) FindQt4 gets, i.e. QT_INSTALL_LIBS:/I/configured/qmake/for/this/root/usr/lib/qt4
4) Obtained QT_INSTALL_DIR is wrong, because it may point to host libraries, required for moc, or somewhere else.
5) Qt4-based application fails to build because of incorrect libraries, supplied for linkage.

> Does the target Qt also have a qmake, moc and uic ?
No, there is no need for them.
They aren't supposed to be run on target machine.
Also, there is no reason of running them on host either.

But again, other cross-environments may have them.

> Is there any relation (installation location-wise) between the moc and uic
> (and qmake) which have to be used and the location of the target Qt
> installation, i.e. the lib and include dirs ?
In general, no.
Any such relation is either quite cross-environment specific or non-existent.
For example,
1) moc and uic are located at /home/me/cross-devel/tools/bin
2) target lib dir is /home/me/cross-devel/build/my_internal_target_name/usr/lib


Again, for original discussion, please look at [1].


[1] http://www.cmake.org/pipermail/cmake/2010-May/thread.html#37215 [^]
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0021186)
Clinton Stimpson (developer)
2010-06-28 22:56

It seems 10718 needs fixed first.

I've tried moving away from NO_DEFAULT_PATH, to let the user set CMAKE_PREFIX_PATH and let the output of qmake be HINTS in find_xxx(), but with multiple Qt installations, it'll get some executables from my chosen Qt installation and some from the default system one.

Other than that, I think I'm pretty close to having this done.
(0021215)
Clinton Stimpson (developer)
2010-07-02 17:49

Support for cross compiling has been merged into cmake git's next branch.
Please try it out and report success/failure.
(0024104)
David Cole (manager)
2010-12-14 18:50

Closing bugs that have been resolved for more than 3 months without any further updates.

 Issue History
Date Modified Username Field Change
2010-06-12 18:09 hippo New Issue
2010-06-12 18:51 Clinton Stimpson Status new => assigned
2010-06-12 18:51 Clinton Stimpson Assigned To => Clinton Stimpson
2010-06-21 13:54 Alex Neundorf Category CMake => Modules
2010-06-28 22:36 Clinton Stimpson Relationship added child of 0010718
2010-06-28 22:56 Clinton Stimpson Note Added: 0021186
2010-06-29 00:14 Clinton Stimpson Relationship deleted child of 0010718
2010-06-29 00:14 Clinton Stimpson Relationship added parent of 0010718
2010-07-02 17:49 Clinton Stimpson Relationship deleted parent of 0010718
2010-07-02 17:49 Clinton Stimpson Note Added: 0021215
2010-07-02 17:49 Clinton Stimpson Status assigned => resolved
2010-07-02 17:49 Clinton Stimpson Resolution open => fixed
2010-12-14 18:50 David Cole Note Added: 0024104
2010-12-14 18:50 David Cole Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team