Building projects for 32 and 64 bit Windows on 64 bit machine

  • Trying to make it possible to build my project for both 32 and 64 bit Windows from my 64 bit Windows 7 machine, using two different Qt 4.7.2 builds. This works fine as long as I don't need to do different things in the .pro file for 32 / 64 bits, but since I want to link with some external libraries, which are in different locations for 32 and 64 bits, I need a way to distinguish between 32 and 64 bit builds in the .pro file.

    "This FAQ entry": describes a way to distinguish between 32 and 64 bit builds using QMAKE_HOST.arch. But that does not really work if you want to enable both 32 and 64 bit builds on a 64 bit machine, since it only tells you the architecture you are building on, not for.

    The easiest way to accomplish what I want would of course be to have different mkspecs for the two Qt builds, but that is not how building Qt for 64 bit Windows works, at least not at the moment. I'm using Visual Studio 2008, so for me both builds are built using the win32-msvc2008 mkspec. I tried introducing my own mkspec win32-msvc2008-64 by just copying the existing win32-msvc2008 mkspec. That did not work at all, though - seems like qmake and/or configure has some built-in knowledge about the different mkspecs.

    The only solution I could come up with that actually works is to build some knowledge about the Qt installation directories into the .pro file, like this:

    X64 = $$find(QT_INSTALL_PREFIX, 64)
    isEmpty(X64) {
    } else {

    This works, as long as the 64 bit Qt is installed in a directory with a path that contains 64, and the 32 bit Qt is not.
    A bit ugly, but the best I could come up with. Any ideas on how to improve this, or do it in some other way, are most welcome.

  • Does using QMAKE_TARGET.arch help? It is not really documented, but you can find some notes on it here:

    We have also added the following FAQ for this:

    "FAQ for QMAKE_TARGET.arch":

  • That does help, in fact it does exactly what I was looking for. Thanks a bunch!

  • in risk of being a tr0ll here, but : going with CMake seems most elegant. At least for me, since Qt is the only dependency falling off my build toolchain :)

Log in to reply

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.