Building 64-bit Qt 4.7 using MinGW-w64

(Nov 12, 2010)

I successfully built 64-bit Qt libraries using MinGW-w64.  Although I had to change Qt source code, it was only one line of code in the current source tree of qt-mingw-w64.  The steps I took to built 64-bit Qt are described below.  Note that my explanation is a bit verbose, as those who just start using MinGW or Qt may need additional information.

1. Obtain Qt 4.7 source code.
• Go to http://gitorious.org/+qt-mingw-w64/qt/qt-mingw-w64-qt
• Click on the 'Source tree' button.  Note that you can directly go to this link.  However, go to the link above allows you to read recent activities of Qt development that may related to you.
• On the right side, you see several 'branches'.  As of Nov 12, 2010, the one you want to use is plain '4.7,' which already merges Webkit facility.
• Once you click on the '4.7' button, you probably need to wait a minute or two.  This allows the server to create tar.gz for downloading.  Basically, the package is prepared on the fly.  This is how gitorious works.
  
  
2. Unpack the source tree to your preferred folder.  For this note, I unpacked it to 'F:\Qt\qt-4.7.1_mingw_w64.'  This path is used here for a demonstration purpose.
   
   
3. Fix file 'src\corelib\tools\qsimd.cpp' by changing line 289 from 'long tmp' to 'quint64 tmp,' as suggested by Jonathan Liu [ref].  See the ref for more information if you don't understand what I meant.  Please note that if you get a newer Qt version, this problem may already be solved.
   
   
4. Get MinGW-w64 from sourceforge.  I use the native compiler for Windows 64-bit.  FYI: MinGW offers a cross-compilation feature.  You can use Linux or 32-bit Windows to produce 64-bit Windows binary.
• Go to http://sourceforge.net/projects/mingw-w64/files/
• Click on Section 'Toolchains targetting Win64'
• Pick the release you like.  I suggest you use personal build from sezero, as sezero usually adds some patches or features that you might want to use (e.g., updated OpenGL and OpenCL headers).  I employed mingw-w64-bin_x86_64-ming_20101003_sezero.zip.  By the time you get MinGW from sourceforge, the build may be gone.  Yet, you are supposed to get a newer version than mine.
• If you wonder what are inside each sezero build see his note in Section 'Toolchains targetting Win64 -> Personal Builds -> sezero_20101003.'  sezero did a good job in bookkeeping (at least it seemed).
  
  
• Personal build of rubenvb is probably an interesting choice, as he appears to be a Qt contributor.  I believe that his MinGW build should not have a serious issue with Qt compilation.
  
  
5. Unpack MinGW to a preferred place.  For this note, it is 'D:\mingw_w64_sezero_oct_3_2010.'
   
   
6. Go to D:\mingw_w64_sezero_oct_3_2010\bin and change gmake.exe to mingw32-make.exe.  Note that it is MinGW's gmake not Qt's qmake.  I backed up original mingw32-make.exe to other file first, although they might be exactly the same binary in the sezero's build.
   
   
7. Download Perl.  Yes, you need Perl to syncqt during compilation.  I suggest ActivePerl Community Edition.  If you want to repeat what I did here, download Windows 64-bit version with an MSI installer.  I did not like Strawberry Perl, as I encountered many issues with it during past summer, especially the fact that it comes with its own GCC.  Its GCC confused me about GCC version since both Strawberry's and MinGW's GCC showed up in the path.  These issues may be already resolved by now, though.
   
   
8. Install Perl.  What a simple task if you have admin right to your machine.  If you don't, see steps below. 
   
• Download AS Package (ZIP).
  
• Unpack and set path to 'base_perl_path/bin' and 'base_perl_path/site/bin.'
• If you want a temporary session path for your command prompt (cmd.exe), type 'set PATH=C:\Perl64\bin;C:\Perl64\site\bin;%PATH%, provided that you unpack its main contents to C:\Perl64 and discard its 'support' folder.  Don't close this command prompt yet because your path settings are temporary.  You need to use it until the end.
  
  
9. Now, you have all you need to embark the actual compilation phase. Set path to your MinGW folder.  For example, 'set PATH=D:\mingw_w64_sezero_oct_3_2010\bin;%PATH%.'
   If you want to know what your current path is, type 'echo %PATH%.'
   
   
10. Set QTDIR variable by typing 'set QTDIR=F:\Qt\qt-4.7.1_mingw_w64\bin.'
    
    
11. Go to Qt base folder (F:\Qt\qt-4.7.1_mingw_w64) and run configure from the command prompt.  You can choose any configure options, perhaps except phonon (my Qt build did not have phonon).  I used 'plain' configure that generated everything, but you might want to get rid of many things, especially qt3 support, examples, and demos.
    
    Update (Feb 18, 2011): it is easy to build Qt with phonon.  The option, however, is off by default for MinGW.  I tested with
    configure -opensource -phonon -no-qt3support -nomake example -nomake demos
    Although I did not test if the created libraries work or not, things are built smoothly.
    
    
12. Type 'gmake.'  Note that if you want to try multi-threaded compilation, type 'gmake -jx,' where x is the number of threads.  For instance, 'gmake -j2' for a dual-core machine, 'gmake -j4' for a quad-core machine, and 'gmake -j6' for a six-core machine (if you want to put every core to work).  I, however, just used gmake with no option since I wanted to simplify everything for this build.
    
    
13. Wait with patience.

The following summarizes downloads and tweaks I made during the above steps.  Basically, we need to do only two things in addition to what most people do with mingw 32-bit.  I have not try building phonon yet (and I think I don't need it for a long time).

Download summary

1. Qt 4.7 mingw-w64 branch (~ 130 MB).  See step 1.
   
2. MinGW-w64 (~ 55 MB).  See step 4.
   
3. ActivePerl (~ 24 MB).  See step 7.
   

Tweak summary

1. Change source code (1 file, 1 line).  See step 3.
2. Change gmake to mingw32-make.exe.  See step 6.  (May not be necessary any more.)
   

Hope this helps,
Pinyo Taeprasartsit

Additional reference: mingw-w64 mail archive


I welcome questions and comments.  Feel free to ask and share if you have any.

VTK Installation on Windows 64-bit for Visual Studio

VTK Installation on Windows 64-bit for Development in Visual Studio

VTK installation in Windows 32-bit is typically painless, as the platform was already tested by many developers and became mature.  (Yet, if you have a problem with it, the troubleshooting note at the end of this page might help.)  For Windows and VTK 64-bit, however, we may encounter a few issues.  This note describes what I did to install VTK 5.6 on my MS Windows 7 Home Premium 64-bit.  This note should be applicable to those who need to do the same thing.

The first part is for installation with default VTK build options.  These options are VTK_USE_CHARTS, VTK_USE_GEOVIS, VTK_USE_INFOVIS, VTK_USE_N_WAY_ARRAYS, VTK_USE_RENDERING, and VTK_USE_VIEWS.

1. Download VTK 5.6 source from http://vtk.org/VTK/resources/software.html.
2. Extract it to create a source folder.
   
3. Open CMake (I used 2.8.1, and it is supposed to work with the most recent version at cmake.org).
4. In CMake, choose a source and binary folders (Figure 1).
   
   
   
   
   Figure 1.  CMake 2.8.1 after source code and binary folder selected.
   
   
5. Click the 'Configure' button.
6. CMake asks about generator (compiler) we want to use (Figure 2).  The one we want to use is Visual Studio 9 2008 Win64 (the one without suffix Win64 is 32-bit) with 'Use default native compiler'.  We can also use Visual Studio 10 Win64 if a target development platform is Visual Studio 10.  Using MinGW will generate incompatible binary for Visual Studio development.  In addition, 64-bit MinGW is quite tricky to use as of Aug 2010.
   
   
   
   
   
   Figure 2. 'Choose compiler' dialog
   
   
7. If initial configuration goes fine, there will be no critical errors and VTK build options will be available for us to choose (Figure 3).
   
   
   
   
   Figure 3.  Build options for VTK after the initial configuration.  Red regions in CMake highlight new options since the previous configuration.  As this is the first time, every option is new and highlighted.
   
   
8. I used the default options.  This option builds a static libraries, which is what I prefer.
   
9. I think options VTK_USE_PARALLEL may help speed up processing in a multi-core system, but I need to learn more about it.  Also, VTK_USE_QT is probably good for me, as I have used Qt a lot recently.  Yet, I need to know what it does first.
10. Click the 'Configure' button again when options are settled.
11. Click the 'Generate' button to generate a proper visual studio solution tree.
12. Go to the output folder specified earlier, you should see 'VTK.sln'.
13. Open the solution and 'Build Solution'.  It will take a while to finish (around 5-10 minutes).  Note that if you only want to use VTK and do not intend to debug into its source code, it is recommend to build it in the release mode.
    
14. In the solution tree, right click on the 'INSTALL' project and 'Build'.  Update Dec 15, 2011: some systems may experience a build error due to write permission to C:\Program Files (x86).  This depends on your Windows settings.  One way to solve this issue is to close Visual Studio and run it 'as administrator' (credit to Alex Southern, see his comment below).
15. The outputs are kept in C:\Program Files (x86)\VTK.  Both include and lib folders are what we are going to use in further software development.
    
16. If you want to build both 32- and 64-bit packages, move the outputs to another folder and repeat the process.  Only the generater in step 6 is needed to change.  We have to move the current outputs because new outputs will be saved to the same folder.
    
    

Build VTK with parallel-processing and Qt-support options

Next, I will discuss installation of VTK with additional options for Visual Studio 2008.  These options are VTK_USE_QT and VTK_USE_PARALLEL.  We can jump to step 7 discussed in the last section. At this point, we only need to check the QT and PARALLEL options and then, hit the 'Configure' button the project again.  CMake will configure the project and comes up with two new options highlighted in red (Figure 4).  Once you set QT_QMAKE_EXECUTABLE to your target version, hit the 'Configure' button for the third time.  If every thing goes fine, you will get a refreshed dialog with message "Configuring done", as depicted in Figure 5.  There are chances that you did not succeed or get a wrong Qt version.  If the latter is your problem, read the caption of Figure 4.  If it fails for other reason, please see the troubleshooting note at the end of this document.  I hope it has what you need.

The rest of the process is generally the same.  If you encounter linking errors when you build VTK in Visual Studio, see Topic 2 in the troubleshooting note provided below.

Figure 4.  CMake after the second configuration with QT and PARALLEL.  QT_QMAKE_EXECUTABLE is selected by what you do with Qt integration for Visual Studio.  In other words, CMake checks the path of default Qt version you set in Visual Studio and use it here.  In fact, CMake and VTK build script strictly use the default Qt version.  You cannot effectively change Qt version here, as it will be eventually reset to the VS default version. Therefore, you may need to open VS and change Qt default version to set QT_QMAKE_EXECUTABLE.

Figure 5. A successful configure dialog.

Troubleshooting Note for Qt Option

1. Problem: "I specified qmake path correctly, but it seems that CMake looks for qmake in a wrong path."

Solution:
You may set QT_QMAKE_EXECUTABLE to point to qmake correctly, but this problem may arise since CMAKE will use outdated qmake properties, such as QT_INSTALL_PREFIX and QT_INSTALL_BINS.  For example, you build Qt in one path and later on you move it to another.  The properties, however, is fixed at the time you build Qt.  You can confirm this issue by going to qmake's make folder and using the command prompt to type 'qmake -query' to see all qmake properties.

If the issue is confirmed, you need to compile qmake again (not the whole Qt library set).  Alternatively, you can just move or copy your Qt directory to the old place to resolve the issue.  If moving or copying Qt folder is not an option, you can quickly re-compile qmake by

• Rename the bin and qmake folders of Qt to something else.
• Copy the pristine bin and qmake folders from the Qt source to the Qt folder.
• Configure Qt from Visual Studio command prompt.  For example, by using 'configure -platform win32-msvc2008 -release -static -opensource -nomake demo -nomake examples -no-qt3support -fast'.  You probably did this before when you compiled Qt libraries.
• Copy things from the old bin and qmake folders to your current bin and qmake folders, but make sure you do not replace the new qmake you just compiled.
• Now, you have qmake with updated qmake properties.  I hope you can configure VTK in CMake as usual from this point.
  
  
  

2. Problem: "I got linking errors when I build VTK in Visual Studio.  It complained about PlaySoundW, WSAAsyncSelect, and many more."

Solution:
Based on my experience, this problem is platform specific.  You may encounter this issue if you use static library version of Qt and the problems in 32-bit and 64-bit platforms are not the same.  These linking problems, however, are related to Windows libraries and occurs when your VTK build script does not correctly include them.

Fortunately, you can include corresponding libraries yourself with ease by following the guidelines described below.

• Identify problematic projects.  Potential problematic projects are QVTKWidgetPlugin, QVTK, QtChartCxxTests, ChartCxxTests, and QVTKCxxTests.
• Search the Internet (or use your prior knowledge, or your MSDN documents) to identify corresponding libraries.  For example, the corresponding library of PlaySoundW is Winmm.lib and that of WSAAsyncSelect is Ws2_32.lib.
• Add the libraries to the Visual Studio project properties, as you do normally.  Basically, you can right click the project in the Solution Explorer of Visual Studio and select 'Properties'.  Then, go to node 'Configuration Properties -> Linker -> Input' and insert the library name to 'Additional Dependencies'.

3. Problem: I checked 'VTK_WRAP_PYTHON' and CMake errors occurred.  It complaint about PYTHON_INCLUDE_DIR AND PYTHON_LIBRARY.

The error message looked like:
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.

Please set them or make sure they are set and tested correctly in the CMake files:

PYTHON_INCLUDE_DIR

PYTHON_LIBRARY

Solution:
The two CMake variables seem to come and go and not consistent over VTK versions.  You might want to add them yourself to CMakeLists.txt.
First, locate IF(VTK_WRAP_PYTHON).  Then, modify the section to something like

IF(VTK_WRAP_PYTHON)
  SET(VTK_LANGUAGES ${VTK_LANGUAGES} PYTHON)
  #Addition by Pinyo
  SET(PYTHON_INCLUDE_DIR "C:/Python31/include")
  SET(PYTHON_LIBRARY "C:/Python31/libs/python31.lib")
ENDIF(VTK_WRAP_PYTHON)

Please note that PYTHON_LIBRARY is the actual library file, not just a folder (although you sometimes see the term python libraries and think that it is a lot of libraries, not a single file.).
Finally, configure and generate make files as usual.


4. Problem: I used VS 2010 64-bit and CMake 2.8.3 and got Q4VTKWidgetPlugin.h(57): error : Undefined interface.  This corresponds to line Q_INTERFACES(QDesignerCustomWidgetCollectionInterface).

Solution:
This is, in fact, a CMake problem.  To be exact, the QT_QTDESIGNER_INCLUDE_DIR is not set correctly.  An example of the value is include/QtDesigner/.  This option is available if we want to generate MinGW Makefiles.  This option also was automatically set in the past and it was correct.  For an unknown reason, it does not work on some machines (VTK 5.6.1 as of Feb 18, 2011).

To solve the problem, go to folder GUISupport\Qt and open CMakeLists.txt.  Then, add a line
SET (QT_QTDESIGNER_INCLUDE_DIR "G:/Workspace/Qt/qt-release-4.7.1-vs2010/include/QtDesigner")
Make sure you adjust the ad hoc path to what suits your computer.

The above line should be added right after FIND_PATH(QT_QTDESIGNER_INCLUDE_DIR QDesignerComponents ...), as the function FIND_PATH may not work correctly in your build.

Hope this helps,
Pinyo Taeprasartsit
(Aug 2010, Feb 2011)