MinGW QT (can be removed Mingwm10.dll, Libgcc_s_dw2-1.dll, Libstdc++-6.dll Dependence, the official MinGW by default are dynamically linked to the GCC library and TDM is a static link to the GCC Library, TDM version better use)

Original Address:MinGW QT Sun 1 East

Problems and workarounds for compiling QT source code using MinGW without using the QT SDK:

Configure-fast-release-no-exceptions-no-rtti-no-stl-no-qt3support-no-opengl-no-multimedia-no-webkit-no-script- No-scripttools-nomake tools-nomake examples-nomake demos-nomake docs-nomake translations-platform win32-g++

The TDM version of MinGW GCC is highly recommended, compared to the official MinGW slow and obscure, the TDM installation process is simple, clear, and fast to update, and the official MinGW developers are also using TDM (why not merge anyway).

"About Mingw10.dll,libgcc_s_dw2-1.dll,libstdc++-6.dll"

Mingwm10.dll is a cleanup function used for thread-safe exception handling, otherwise there will be a memory leak.

Libgcc_s_dw2-1.dll is the core runtime of GCC.

Libstdc++-6.dll is the runtime for a specific language C + + supported by GCC.

The QT Library, compiled before mingwrt3.18, is dependent on Mingwm10.dll by default. Compiling QT libraries with mingwrt3.18 no longer relies on mingwm10.dll. Compiled QT library can not be compressed with UPX, this confirmation is UPX bug, because the use of aspack is not a problem. If you want to get rid of dependencies before 3.18, because QT itself does not use exception handling, so you can configure in the time, the option-no-exceptions prohibit exception processing to remove the dependency on Mingwm10.dll, and so the compiled QT library volume also reduced a lot.
with the official gcc4.4.0 compiled QT library, the default dependency libgcc_s_dw2-1.dll,gcc-4.5.0 default more than one dependent Libstdc++-6.dll. The official MinGW default is a library of dynamically linked GCC and TDM is a statically linked GCC library. Use official MinGW to remove Libgcc_s_dw2-1.dll dependencies on the GCC core library, you can modify qtdir/mkspec/win32-g++/qmake.conf,qmake_lflags before compiling the QT library: STATIC-LIBGCC. or configure after modifying Qtdir/.qmake.cache,qmake_lflags + =-STATIC-LIBGCC. Cancels the dependency on the C + + runtime Libstdc++-6.dll, using the option-static-libstdc++. Modify Qtdir/.qmake.cache by the way, you can also choose not to compile examples,demos and so on, just keep libs. Or configure, specify-nomake tools-nomake examples-nomake demos-nomake docs-nomake Translations

Relative to the official mingw of the complex, using the TDM version of the MinGW benefits a lot, first, the installation process is simple and clear, the second generation of the QT library is not dependent on libgcc_s_dw2-1.dll,libstdc++-6.dll, and if used tdm-gcc-4.5.0 ( mingw-runtim-3.18), even mingwm10.dll is not needed. TDM has two versions, SJLJ and DW2, which are two different kinds of exception handling, SJLJ is the old way, slow, may be more stable, dw2 is a new way, faster. The tdm4.5.0 default is SJLJ, and of course the DW2 version is provided. In addition to the download official online dw2 version of the file, may need to next libexpat-2.0.1-1-mingw32-dll-1.tar.gz, (do not know what will be missing), because I tried to use the On-demand installation, choose Dw2, He's going to install Libexpat.dll. Then rename all the-dw2 with no dw2, such as G++-DW2 renamed the G++,TDM Note that the two versions can coexist peacefully, and how to do it later.

"Garbled compilation using GCC 4.4.0"

The gcc4.4 automatically detects the current locale and produces the corresponding output. If you want to use a pure English environment, set the environment variable lang=c or Lang=en_us.

"Sometimes compiling QT will make a mistake: Qtvariantproperty.cpp:1927:internal compiler Error"

The specific reason is unknown, some people say it is GCC bug, I suspect with memory usage. So it's best to avoid other actions during the compilation process, which can greatly reduce the chances of this happening. However, since sometimes this problem will have to have a solution, after the study can be: first go to qtdir/tools/designer/src/lib, delete the TMP directory and all qmake generated makefile, manual qmake, Generate makefile, at this time do not make, although this can be successful, but the subsequent compilation cannot continue, so go back to the Qtdir directory, then make.

"Compile qt4.6.2 with gcc4.5.0, error 0xc00000005"

According to Gcc4.5.0 's instructions can not be resolved, in fact, QT conf file has been added to have such options.

Use tdm-gcc-4.5.0 (either SJLJ or DW2).

"The phonon module is not compiled when QT is compiled by default"

MinGW need to hit the corresponding patch in all the files to Mingw/include, in order to use the patch also need to download Msys and Patch,patch usage: Patch < Dshow.patch, so the patch is ready. This will automatically detect the system support phonon when configure QT, so the Phono library will be compiled. A separate installation of Msys (core) that uses certain commands will appear warning:terminal is not fully functional (press RETURN), which is because no/etc/termcap is set, Use the Msys Full installation version of the termcap below it can be, or simply use the complete installation of the Msys, is the version slightly older, that basically everything has.

"Compiling Dbus"

Dbus and phonon, also need additional support to compile, first download Windbus, address Src/dbus make

"After QT installation, change the location of Qt"

Qt compiled directory can not be renamed, or there will be a file can not find the situation, QT compile the current QT path hard coding to the QT Library and Qmake, and so on, so can not be renamed. If you want to change your name:

1. Using the Qpatch, this is a qtcreator with a small tool, when installing the QT SDK, the installation program is to run Qpatch to change the QT installation directory. How to use: Qpatch files-to-patch-windows oldqtdir newqtdir. Assuming the original installation directory is c:qt2010.04, the renamed directory is c:qt2000.00. Run the command line, enter the C:qt2000.00bin directory, Qpatch files-to-patch-windows c:/qt/2010.04/qt c:/qt/2000.00/qt, The list of replacement files specified by Files-to-patch-windows is located under the Qt directory, which means that Prefix=c:/qt/2010.04/qt,qpatch will be based on c:/qt/2000.00/qt+ Files-to-patch-windows find all the files that need to be replaced. Here need to pay attention to the case, grandma, it seems that QT engineers also have a lot of lack of mind, Windows Comparison directory string Incredibly is case sensitive, harm I thought about a half-day, obviously look at this path incredibly replace, fortunately, the old one flash, hmm. I'm so smart. There is a limit to the use of Qpatch is renamed after the directory length can not be greater than the original length, which is why the installation package is not extracted from the default directory is a long string of reasons.

2. There is also a way to use qt.conf:, to create a file qt.conf under Qt/bin, with the following contents:

[Paths]
Prefix = c:/xxx/yyy

The foreigner says the directory that prefix points to must contain. License-evaluation This file, of course, is generally the case.

This allows you to build multiple QT versions from one place into a different location, and when compiled, the unwanted directories can be deleted, the BIN,LIB,PLUGINS,TOOLS,INCLUDE,SRC retained, Mkspecs. This qtcreator will correctly recognize the different versions of QT.

"Qtcreator F1 get context Help, show no documentation available"

Especially with multiple versions of QT, which can easily cause this confusion,

Under XP system, remove C:documents and settingsadministratorapplication Datanokia.

Win7 System, delete C:usersdarkappdataroamingnokia

Restart the qtcreator again.

"Qtcreator1.3.1->tools->options->qt versions->debugging helper shows Red Fork fork"

First rebuild, everything is normal, will be in the Qtdir/qtc-debugging-helper directory generated Gdbmacros.dll, so it turns green tick. However, although you can find the helper library, but in the debugging program is still not correctly display QT class and STL, hint debugging helpers not found, Jinshan typing pass 2010 free download. After repeated verification, found that the reason is the GDB version mismatch, I installed the MinGW with gdb7.1 and debugging helper can only support to gdb6.8. The workaround is to use GDB in the Qtcreator MinGW or your own next gdb6.8. There is also a situation that seems to have to be in the QT program (at least Qtcore), the pure C + + program will also prompt debugging helpers not found.

"QT 4.6.3 use error after static compilation"

There is no problem with the compile process, but the error when using LIBQTGUI.A:

Undefined reference to ' _IMP___Z21QT_CALL_POST_ROUTINESV '
Undefined reference to ' _imp___z21qdeleteineventhandlerp7qobject '

This is the QT bug, using 4.6.2 no problem

"Compile Options Miscellaneous"

Modify $qtdirmkspecscompilerqmake.conf, where compiler=win32-g++ or msvc-2008

win32-g++: Qmake_cflags_release =-os-momit-leaf-frame-pointer
Msvc-2008:qmake_cflags_release =-O1-OG-GL-MD

For anyone who's interested in a compiling fully static libraries for msvc (no msvcrtXX.dll dependence), your need change The Qmake_cflags_release from-md to-mt, and Add/nodefaultlib: "MSVCRT" to the qmake_lflags_release.

TDM version dw2, not renamed, compiled even with: GCC-DW2,G++-DW2,CPP-DW2,MINGW32-GCC-DW2, etc.

First modify the qtdir/qmake/makefile.win32-g++:

CXX = g++-dw2

Linkqmake = g++-dw2 $ (lflags)-O Qmake.exe $ (OBJS) $ (QTOBJS) $ (LIBS)

In this way, the qmake can be generated normally, followed by the QT Library,

Re-Modify Qtdir/mkspecs/win32-g++/qmake.conf

QMAKE_CC = gcc-dw2

Qmake_cxx = g++-dw2

Qmake_link = g++-dw2
Qmake_link_c = gcc-dw2

QMAKE_RC = Windres--preprocessor=cpp-dw2

Note that the last windres call to GCC,GCC and the CPP, so, the direct cpp-dw2, or can not find.

"Qwt and general designer plugins"

QWT is a library of drawing charts, as well as a designer plug-in integration into the qtcreator, the issue to be noted here is

IDE and compiler mates: if you are using Qtsdk's own qtcreator, because it is compiled with MSVC, in order to make QWT plug-in can be qtcreator recognized, you must use MSVC compile QWT, generate two DLLs, one is QWT The designer plugin Qwt_designer_plugin5.dll this in the Qtcreator Designer directory, but running Qtcreator still cannot display the QWT plug-in because it also relies on qwt.dll. Then put the Qwt5.dll in the bin directory qtcreator, so that the qtcreator can see the QWT plug-in. However, when the application uses the QWT class library, since the QT SDK compiler is MINGW, you must use MINGW to recompile the QWT class library, the generated designer plug-in is not needed, and the resulting libqwt5.a is placed in qt/ Lib or anywhere, this import interface library is just for compilation to succeed, the generated Qwt5.dll is placed under Qt/bin, or directly in the executable directory, this is the runtime really to invoke.

Understand the above, then of course, the better way is not without the QT SDK, but unified use msvc compile, so this combination: Download a separate qtcreator (the default is MSVC compilation) +QT library msvc, so just compile once qwt.

Download Msvc Express, install
Download a separate QT creator (default with MSVC compilation), install
Download QT Libraries (msvc version), install
Open Qtcreator to specify the compilation environment to use QT (version msvc) that you just downloaded and installed
Download qwt-5.2.1 source code, unzip
Open QWT project with Qtcreator, compile release version
Put the Qwt-build-desktopdesignerpluginsdesignerqwt_designer_plugin5.dll in the Qtcreatorbindesigner directory
Put the Qwt-build-desktoplibqwt5.dll in the Qtcreatorbin directory
Rerun Qtcreator you will see a control that already has qwt in the designer, but it cannot be applied to the program
To make the QWT control available in your program, you need to do a few more things
Put the qwt-build-desktoplibqwt5.lib in the Qtlib directory
Put the Qwt-build-desktoplibqwt5.dll in the Qtbin directory
Rerun Qtcreator, create a new project, drag a Qwt control onto the form
. Pro adds:
LIBS + =-lqwt5
Includepath + = Qwt-5.2.1src Use your own path here
Now we can try the effect.

"LIBS vs Libs_private"

First remember that there is no space behind Libs or libs_privte,-lpath-lname. If there are spaces in path

$ $quote (-lpath), you can use "" or "/" in path, you do not need to escape "".

Sometimes it's weird, libs-l "path"-L "name" doesn't work, and it's qt/lib the default.

Consider using libs_private at this point, but not the direct full path.

"Multi-Core compilation"

Mingw32-make parameter Settings--jobs or-j x, X is the number of processors +1, seemingly does not work, set the Makeflags=-j3 is not, perhaps according to the environment automatically-jx it?

Qtcreator automatically uses JOM instead of NMAKE, my dual-core, Jom-j 2, and CPU usage is up to 100%.

"Meta Object System"

In addition to implementing the Signal/slot, the Meta object system implements the extension Rtti of C + +, similar to reflection in Java, which gets all the information of the class at run time.

Because of the qmake? Q_object in CPP (usually very few people? put Q_object in. cpp, but in. h), so if the. cpp has Q_object?,?? Born undefined reference to ' vtable for XXX????. Add # include "Xxx.moc" to the Xxx.cpp end (make sure to put the last line)

"MinGW DLLs and Msvc DLLs"

Different compiler implementation DLL export name (name mangling) is different, for function export, we can use a unified, through the extern "C" processed by the non-decorated name to achieve interoperability, and the export of the class is much more complex, involving the ABI (application Binary Interface) is subject to further discussion.

App call DLLs can be divided into 4 scenarios:

1.mingw app calls MinGW DLL

Of course dies know dies, pro directly libs + = Mingw.dll can, even do not need. A or. lib

2.msvc app calls MinGW DLL

Msvc app shelves big, do not recognize others, directly use MINGW.A Import library is not, at least release app does not, debug app Pour still can run, reason unknown. The correct approach is to generate the Lib interface required by the MSVC app for tools that use MSVC. In order to generate the Lib interface, we need to have a DEF file, which can be generated automatically when compiling the MinGW DLL, joining the link option: qmake_lflags + =-wl,--output-def,xxx.def. With Def the next thing is easy. Execution: Lib/machine:i386/def:xxx.def. This generates the Xxx.lib and a useless xxx.exp required by the Msvc app.

And then Pro libs + = Xxx.lib on the line.

3.mingw app calls Msvc DLL

The same 1. Direct libs + = Msvc.dll

Usually (Read:for all DLLs created with MinGW and also a few others) MinGW links fine against a DLL. No import library is necessary.

4. Msvc App calls Msvc DLL

Nothing to say.

"Using Qttest"

QT + = Testlib or CONFIG + = Qtestlib

Http://blog.sina.com.cn/s/blog_930982070101edqf.html

MinGW QT (can be removed Mingwm10.dll, Libgcc_s_dw2-1.dll, Libstdc++-6.dll Dependence, the official MinGW by default are dynamically linked to the GCC library and TDM is a static link to the GCC Library, TDM version better use)