Qt with MinGW-w64?

  • Hi -

    I recently began building an app on a new Windows box (after previously confining my attention to the Mac). I just noticed that I'm using a 32-bit version of MinGW. I browsed through the forums, and see that, at least in prior versions of Qt (I'm using 4.8), it was necessary to build Qt from source in order to use the 64-bit compiler. Is this still the case?

    If I can avoid it, I'd prefer not to hassle with building Qt myself, but I kind of hate to see an i7 processor being throttled by 32-bit instructions. This application is quite CPU intensive.

    Thanks for any input.

  • There are no prebuilt binaries for MinGW 64bit on Windows. You'll have to build manually, sorry.

  • OK, no big deal (I hope). Is it just a matter of downloading the source and following the README instructions? Any "gotchas" I should be aware of?


  • Not that I'm aware of any. But I only built it using the 32bit version, I never tried 64bit MinGW.

  • OK, a couple of specific questions regarding "step 4":http://qt-project.org/doc/qt-4.8/install-win.html#step-4-build-the-qt-library:

    1. can I run these commands from a standard shell window instead of from Visual Studio?
    2. here's where I want to use my 64-bit version of MinGW, right?
    3. minor question: since I don't want to overwrite my pre-built version, I'll need to give the new version a different name. I know you build your own; do you use a particular naming convention to keep everything straight?

  • You must run the commands from a MSYS command prompt. Don't open the MSVS command prompt - it will clutter your environment! The MSYS should be available somewhere within your MinGW 64 installation. And make sure, it's the 64 bit version you are in!

    On Windows, I just extract the sources and use a in-source build of Qt for my further development. In Qt Creator, go to the settings and add the MinGW 64 bit toolchain to the list of toolchains and once your Qt build is ready, just add it to the list of Qt versions. You will have to point out the qmake.exe - the name you give it is up to you. For example, "Qt 4.8.0 MinGW 64" wouldn't be a bad choice :-)

  • I installed TDM-GCC (recommended by SourceForge), and downloaded a MSYS separately, since one didn't seem to be included. But, its commands don't match the ones in the Qt install document.

    Struggling through this stuff makes me feel like a moron...it seems as though everything I try runs into a snag of some kind. I tried manually adding TDM to the tool chain, but that didn't work, either. Maybe I should move the new compiler into the Qt directory structure; I'm not even sure I'm choosing the correct bin file (there are several to choose from in the /bin directory).

    Might be time to punt on this one...

  • I would strongly recommend against moving stuff into the Qt (SDK) installation manually, danger to wreck something is too big.

    I never used a MinGW 64 build, so I have no experiences on how easy or difficult it is to build Qt on that. I remember that there have been some threads in that though. The forum search will dig them up.

  • Just for the record: building Qt 4.8 using the latest GCC 4.7.0 (as for example in MinGW64) requires a patch for building JavaScriptCore:

    • struct JSGlobalObjectData : public JSVariableObjectData {
    • struct JSGlobalObjectData : public JSVariableObject::JSVariableObjectData {


    • struct JSStaticScopeObjectData : public JSVariableObjectData {
    • struct JSStaticScopeObjectData : public JSVariableObject::JSVariableObjectData {

  • @Lukas:
    Just as a side question: Can you recommend a particular MinGW64 version/flavor? I'm aware of at least two: "MinGW 64 @ sourceforge":http://mingw-w64.sourceforge.net/ and "TDM-GCC":http://tdm-gcc.tdragon.net/.

  • I'm currently using the personal build of rubenvb for both, "32-bit":http://goo.gl/SydTf and "64-bit":http://goo.gl/RNxso, which can be used as a drop-in replacement for the MinGW that comes with the SDK. The automated builds are prefixed and usually missing SDK headers (for example Direct3D/DirectShow, which prevents phonon from building).

    I'm currently migrating to 4.7.0-2 for better C++11 support and except the issue mentioned above it compiles fine so far (although the are a lot of warnings for some modules, which will require further investigation). I should mention that I haven't built webkit so far, as it takes ages to compile (which nevertheless should not suffer from the issue above, as it uses a different version of JavaScriptCore).

  • Thanks for the infos. Looks like I'll wait some time to migrate to MinGW 64. We'll have to ship 32 bit windows binaries for the next couple of years anyways, so there's not much harm with this.

  • with webkit it fails with "Memory exhausted" error on linking debug version of webkit . even -fno-keep-inline-dllexport does not help :(

  • I've compiled Webkit without any problems (except it takes quite a few hours) with both, MinGW32 GCC 4.7.0-2 and MinGW64 GCC-4.7.0-2 on Windows 7 64.

    Are you using a 32-bit operating system?

  • win7 x64.

    $ gcc --version
    gcc.exe (tdm64-1) 4.6.1

    configure.exe -debug-and-release -opensource -no-qt3support -nomake examples -nomake demos -qt-style-windows -qt-style-windowsxp -qt-style-windowsvista -openssl -I C:\local\include

    fails on linking debug version of qtwebkit

    I'm now recompiling everything from scratch. will see..

  • linked with x86_64-w64-mingw32-gcc-4.7.0-3_rubenvb! =)
    so tdm-gcc-4.6.1 has bugs

  • I am working with x86_64-w64-mingw32-gcc-4.7.2-release-win64_rubenvb at the moment.
    I had several times a compile issue in a file called unknwn.h. (line 70)
    I found a solution in some forum thread from rubenvb.
    In the makefiles from all directories called headersclean, you have to remove the -ansi flag from the CXXFLAGS.

    I used:
    configure -debug-and-release -opensource -confirm-license -platform win32-g++ -developer-build -c++11 -icu -opengl desktop -openssl -plugin-sql-odbc

Log in to reply

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