MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013060CMakepublic2012-03-23 14:362013-01-09 14:05
ReporterClaus Christmann 
Assigned ToClinton Stimpson 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformPCOSopenSuSEOS Version12.1
Product VersionCMake 2.8.6 
Target VersionFixed in Version 
Summary0013060: FindQt4 relies on the command 'qmake -query QT_INSTALL_LIBS' to determine the lib path and ignores FIND_LIBRARY_USE_LIB64_PATHS
DescriptionThe FindQt4.cmake file which underlies find_package(Qt4) ignores the global property FIND_LIBRARY_USE_LIB64_PATHS. It starts searching for the Qt4 libraries with a HINT set to the output of an EXECUTE_PROCESS() call to 'qmake -query QT_INSTALL_LIBS' which always only seems to return the location of the 64 bit libraries (and plugins, and imports, and examples).
Steps To ReproduceSimply run this CMakeLists.txt (also attached) and look at the output:

project(findqt4_test)
cmake_minimum_required(VERSION 2.8)

# being lazy
macro( message_variable VAR_NAME )
  message(STATUS ${VAR_NAME}=${${VAR_NAME}})
endmacro( message_variable VAR_NAME )

# setting and checking the property
set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS OFF)
get_property(use_lib64_paths GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS)
message_variable(use_lib64_paths)

find_package(Qt4 REQUIRED)
include( ${QT_USE_FILE} )

message_variable(QT_BINARY_DIR) # Path to "bin" of Qt4
message_variable(QT_LIBRARY_DIR) # Path to "lib" of Qt4
message_variable(QT_PLUGINS_DIR) # Path to "plugins" for Qt4
message_variable(QT_IMPORTS_DIR) # Path to "imports" of Qt4

message_variable(QT_LIBRARIES)
Additional InformationI started messing with the FindQt4.cmake and wrapped the library finding part in a big IF() ENDIF() on the propery FIND_LIBRARY_USE_LIB64_PATHS and that worked. However, I then realized that I also would have to do that for the plugins and imports.

As I realize that FIND_LIBRARY_USE_LIB64_PATHS actually should effect something inside the FIND_LIBRARY() calls, my workaround clearly started from a wrong approach. However, as FindQt4 is written in a way which doesn't seem to allow to use the property inside the FIND_LIBRARY() calls (it sets a HINT and at the same time NO_DEFAULT_PATHS), my wrapper seemed to circumvent this.

Bottom line: I just don't know enough cmake to fix this "the right way", hence I am just reporting this without also submitting a patch.


PS: As an aside note, I found that my distro (openSuSE 12.1 x86_64) doesn't set non-versioned symlinks for the 32bit libraries of qt, i.e. /usr/lib only contains libQt*.so.4 symlinks and no libQt*.so ones. I had to create those by hand so that find_library(QtCore) would actually return a result from the non-lib64 path.
TagsNo tags attached.
Relationships
Attached Filestxt CMakeLists.txt (739) 2012-03-23 14:36
https://public.kitware.com/Bug/file/4262/*
Issue History
Date ModifiedUsernameFieldChange
2012-03-23 14:36Claus ChristmannNew Issue
2012-03-23 14:36Claus ChristmannFile Added: CMakeLists.txt
2012-03-23 15:40Brad KingAssigned To => Clinton Stimpson
2012-03-23 15:40Brad KingStatusnew => assigned
2012-03-28 11:28Clinton StimpsonNote Added: 0028987
2012-03-28 14:01Claus ChristmannNote Added: 0028989
2012-03-28 14:08Claus ChristmannNote Added: 0028990
2012-03-28 14:47Clinton StimpsonNote Added: 0028991
2012-08-13 23:19Clinton StimpsonNote Added: 0030631
2012-08-13 23:19Clinton StimpsonStatusassigned => resolved
2012-08-13 23:19Clinton StimpsonResolutionopen => no change required
2013-01-09 14:05Robert MaynardNote Added: 0032062
2013-01-09 14:05Robert MaynardStatusresolved => closed

Notes
(0028987)
Clinton Stimpson   
2012-03-28 11:28   
What does qmake -query QT_INSTALL_LIBS return?

Does your distro have
/lib64 (64 bit)
/lib (32 bit)

or
/lib (64 bit)
/lib32 (32 bit)

or something else...

And you are trying to build 32 bit, correct?

I'm confused, because one doesn't normally set FIND_LIBRARY_USE_LIB64_PATHS like that, because it makes the script less portable. It should automatically be set according to your system.
(0028989)
Claus Christmann   
2012-03-28 14:01   
I am running opensuse 12.1 x86_64 and need to support a CMakeLists.txt that allows the compilation of a Qt dependent application both as 32bit as well as 64 bit.

On my system I have the standard 64bit devel package for Qt, providing the 64bit libs in /usr/lib64. I then copied the 32devel libs from the 32bit repository into /usr/lib.

If I use the qmake to query, I get these results:

:~> file /usr/bin/qmake
/usr/bin/qmake: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, BuildID[sha1]=0xdb4713fedf41e7ba1b6ad6bda6b2878ce33960c7, stripped
:~> /usr/bin/qmake -query QT_INSTALL_LIBS
/usr/lib64

:~> file ~/Downloads/usr/bin/qmake
/home/claus/Downloads/usr/bin/qmake: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, BuildID[sha1]=0x9980b1eb6f172623bf509a4dc27a6049a97ce3c3, stripped
:~> ~/Downloads/usr/bin/qmake -query QT_INSTALL_LIBS
/usr/lib

so, as expected, the 32bit qmake returns the 32bit paths, the 64bit qmake the 64bit paths.

My current work around is as follows (effectively blocking the find_library calls in FindQt4.cmake):

project(findqt4_test)
cmake_minimum_required(VERSION 2.8)

# being lazy
macro( message_variable VAR_NAME )
  message(STATUS ${VAR_NAME}=${${VAR_NAME}})
endmacro( message_variable VAR_NAME )

option(BUILD_NATIVE_64_BIT "Do you want to build a native 64bit target?" OFF)


# setting and checking the property
set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS ${BUILD_NATIVE_64_BIT})
get_property(use_lib64_paths GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS)
message_variable(use_lib64_paths)



# this is a really really bad hack to force find_package to "find" the 32bit version of Qt4
# find_library(TMP_LIB_QtCore QtCore)
unset(QT_QTCORE_LIBRARY_RELEASE CACHE)
find_library(QT_QTCORE_LIBRARY_RELEASE QtCore)
message_variable(QT_QTCORE_LIBRARY_RELEASE)

get_filename_component(TMP_QT_LIBRARY_DIR ${QT_QTCORE_LIBRARY_RELEASE} PATH)
set(QT_LIBRARY_DIR ${TMP_QT_LIBRARY_DIR} CACHE PATH "" FORCE) # Path to "lib" of Qt4
set(QT_PLUGINS_DIR ${TMP_QT_LIBRARY_DIR}/qt4/plugins CACHE PATH "" FORCE) # Path to "plugins" for Qt4
set(QT_IMPORTS_DIR ${TMP_QT_LIBRARY_DIR}/qt4/plugins/imports CACHE PATH "" FORCE) # Path to "imports" of Qt4
message_variable(QT_LIBRARY_DIR)

find_package(Qt4 REQUIRED QtCore QtGui QtNetwork QtXml )
include( ${QT_USE_FILE} )



message_variable(QT_LIBRARY_DIR) # Path to "lib" of Qt4
message_variable(QT_PLUGINS_DIR) # Path to "plugins" for Qt4
message_variable(QT_IMPORTS_DIR) # Path to "imports" of Qt4

message_variable(QT_BINARY_DIR) # Path to "bin" of Qt4
message_variable(QT_LIBRARY_DIR) # Path to "lib" of Qt4
message_variable(QT_PLUGINS_DIR) # Path to "plugins" for Qt4
message_variable(QT_IMPORTS_DIR) # Path to "imports" of Qt4

message_variable(QT_LIBRARIES)
(0028990)
Claus Christmann   
2012-03-28 14:08   
Addendum to my previous note:

Note, however, that this still doesn't really work, as the QT_LIBRARIES are not really affected... :/
(0028991)
Clinton Stimpson   
2012-03-28 14:47   
If you want a 32/64 bit switch, its my understanding that it must be done before your project() call, and you must set up the -m32 flag correctly before the first project() call. The first project() call inspects the system, checks sizeof(void*), automatically sets FIND_LIBRARY_USE_LIB64_PATHS, and other things that find_library() depends on.
Also, if you have the switch, you shouldn't allow it to be switched the other way after the first configure. Having such a cmake switch would not make sense for Visual Studio or Xcode.
Also, the FIND_LIBRARY_USE_LIB64_PATHS is not a 32 bit vs 64 bit flag... its a flag for whether the system stores 64 bit libraries in lib/ or lib64/. My Linux machine has 64 bit libraries in lib/, not lib64/.

Ideally, you wouldn't have a switch, but expect the user to set CFLAGS/CXXFLAGS environment variables to contain -m32.
(0030631)
Clinton Stimpson   
2012-08-13 23:19   
I haven't heard back.. so I'm assuming this is user error by not setting the environment to 32 bit before the first project() call.

Feel free to get back to me if you actually set 32 bit up front like this with an empty build tree.
$ CFLAGS=-m32 CXXFLAGS=-m32 cmake /path/to/src
(0032062)
Robert Maynard   
2013-01-09 14:05   
Closing resolved issues that have not been updated in more than 4 months.