When building programs with QT that you want do distribute to your friends, I found it preferable to compile the QT library myself.
On Mac OS X this was nice, because I could choose architecture combination for my binaries exactly as I wanted (PPC only, or PPC32 + x64, for example).
On Windows it was nice because I could download the latest Windows Platform SDK (which is free!) and build QT with it. That way, I could create both x86 and x64 Windows binaries that could be distributed along with no other files whatsoever.
However, building QT takes a long time. And if you are unlucky or too ambitious with your configure switches, it might not build at all. So, here are simply a few working configurations:
Mac OS 10.5, PPC, XCode 3.1.3, QT 4.5.3
# qt_conf_carbon-ppc_x86.sh ./configure -release -no-qt3support -nomake examples -nomake demos -arch ppc -arch x86 -platform macx-g++42 -sdk /Developer/SDKs/MacOSX10.5.sdk/ -prefix /Users/zo0ok/qt_dev/4.5.3-carbon-ppc_x86 # qt_conf_cocoa-ppc.sh ./configure -release -no-qt3support -nomake examples -nomake demos -arch ppc -cocoa -platform macx-g++42 -sdk /Developer/SDKs/MacOSX10.5.sdk/ -prefix /Users/zo0ok/qt_dev/4.5.3-cocoa-ppc # qt_conf_cocoa-ppc_x64.sh ./configure -release -no-qt3support -nomake examples -nomake demos -arch ppc -arch x86_64 -cocoa -platform macx-g++42 -sdk /Developer/SDKs/MacOSX10.5.sdk/ -prefix /Users/zo0ok/qt_dev/4.5.3-cocoa-ppc_x64 # qt_conf_static-ppc.sh ./configure -static -release -arch ppc -sdk /Developer/SDKs/MacOSX10.5.sdk/ -no-framework -prefix /Users/zo0ok/qt_dev/4.5.3-static-ppc # qt_conf_static-ppc_x86.sh ./configure -static -release -nomake examples -nomake demos -arch ppc -arch x86 -platform macx-g++42 -sdk /Developer/SDKs/MacOSX10.5.sdk/ -no-framework -prefix /Users/zo0ok/qt_dev/4.5.3-static-ppc_x86
Please refer to the QT documentation to understand the advantages of carbon vs cocoa. Note that all those configurations are made on (and for) a PPC target. You might just want x64 if you build for modern Macs.
Mac OS 10.6, x64, XCode 3.2.6, QT 4.7.3
$ ./configure -release -no-qt3support -nomake examples -nomake demos -arch x86_64 -cocoa -platform macx-g++42 -sdk /Developer/SDKs/MacOSX10.5.sdk/ -prefix /Users/zo0ok/qt_dev/4.7.3-cocoa-x64
For some reason I got linking error an hour into the building process when using the MacOSX10.6 sdk. But those of you who are cutting edge dont use 10.6 and 3.2.6 anyways.
Windows SDK 7.0, x64 OS, QT 4.6.1
If you install the (free) Windows SDK 7.0 you get all compilers and make tools you need (you can use Visual Studio C++ Express, but it does (did) not build for x64.
Now, in the Windows world, compiling for different target cpus is quite simple (but a bit confusing). When you build QT the build happens in two steps. In the first step (configure) some tools are compiled (qmake, and more). That qmake will be used to build the rest of qt in the second step.
If you “cross compile” on Windows you will first use x86 MS tools to build x64 QT tools. In the second step (nmake) x86 and x64 tools will end up being mixed and you get problems (linking problems if I remember correctly. So, the easiest way to get it right is to not cross compile but:
- Build x64 QT using native x64 Microsoft tools
- Build x86 QT using native x86 Microsoft tools
This is easy, on an x64 version of Windows, as it runs x86 programs just fine. I really have to put a screenshot here, because there is no other way to explain this Microsoft mess:
The executables you see (cl, the C compiler, for example) are the x86 tools generating x86 binaries. You use those tools if you invoke vcvars32.bat. But then there are four folders containing the same tools for different other combinations:
|amd64||vcvars64.bat||Create x64 on x64 (USE)|
|x86_amd64||vcvarsx86_amd64.bat||Create x64 on x86 (avoid)|
Dont even bother with the irrelevant ia64 stuff. When you have a shell with environment from the correct vcvars file, this is how to build QT (exactly the same for both versions):
> configure.exe -static -release -no-qt3support -platform win32-msvc2008 > nmake sub-src sub-tools
Note: on Windows it was best to build qt “in place” (no -prefix used). So, I suggest you install the qt source to two different folder: c:\qt-x86 and c:\qt-x64. When you are done you can make your own copies of the vcvars-files and add qt\bin-folder to the path.
On Windows it is clever to add to your .pro-file:
CONFIG += embed_manifest_exe
That way, the exe file is the only thing you need to distribute (well, people might need the right c/c++ runtimes installed).
Your friends running Linux can compile from source