[Solved] Qt 5.0.2 MinGW binary distribution messed up my system?!
I got the feeling that the Qt 5.0.2 MinGW binary distribution (http://download.qt-project.org/official_releases/qt/5.0/5.0.2/qt-windows-opensource-5.0.2-mingw47_32-x86-offline.exe) messed up my system.
I am working on an application written with Qt 4.8.1 (compiled with MinGW-w64 4.5.4) and now I wanted to port it to Qt 5.0.2. So I installed Qt 5.0.2, done all the porting (fixed the includes, added the new modules in the project file, fixed code incompatibilities) and the application compiles. After putting all the needed DLLs in the folder of the EXE, the application runs but crashes in a call of QNetworkAccessManager::get() although the same code line has already run a few times before. This behavior is reproducible (crashes always at the same location). The debugger gave me messages like "warning: Invalid parameter passed to C runtime function.". After some playing around with this, I gave up and went back to the Qt 4.8.1 version (checked out prevision revision of the code from svn, uninstalled Qt 5, compiled the application). But now, the application crashes at the same location as the Qt 5.0.2 version! However, it runs fine on a system of a colleague (I just copied it over to his system).
All changes that I made to the system were installing Qt 5, ActivateState Python, Ruby (both listed as requirements in the Qt 5 README) and installing a Windows Update (which included a security update for the Visual C++ Redist).
I already uninstalled/reinstalled the MSVC Redist which where listed in the "Programs and Features" dialog but that didn't help.
So all I could think of is, that there are some leftovers of Qt 5, MinGW 4.7 or the MS Visual C++ Redist on my system (registry? windows system folders?).
I'm running on Win7 64bit.
GCC 4.5 is incompatible with GCC 4.7, IIRC. Did you make sure that your system is compiling with the correct version of the tool chain, and linking to the correct version of the MinGW DLLs? (e.g. make sure that the "wrong" MinGW binaries are not in your PATH, when compiling and when running.) The Qt binaries were built with GCC 4.7, so you must use GCC 4.7 to build your app.
Did you fully clean your build tree before compiling with Qt 5.0.2?
It could also be due to a previously-undetected bug in your code (e.g. using pointers to unallocated memory) -- these kinds of bugs don't always cause crashes immediately, but they tend to go unnoticed for a long time. Try attaching a debugger (GDB for MinGW) to see what causes the crash.
MinGW does not use Visual C++ Redistributable, so that shouldn't be a factor. Qt does not change the registry, except if you choose to make Qt Creator the default program for opening Qt/C++ files. All Qt binaries are restricted to the folder where you installed Qt -- they don't go near any Windows system folders.
The message from the debugger (see my first post) sounds like there is something wrong with the different compiler versions but I double checked that the MinGW 4.7 directory was on PATH and no other. And I deleted all object files, moc or uic generated files, makefiles, object_scripts and all binaries before compiling.
However, at least I solved the problem with the Qt 4.8.1 version. I uninstalled and deleted everything from MinGW, Qt and Visual C++ Redistributable I found, then rebooted and afterwards, the application worked again.
Somehow, I got the impression that the Visual C++ Redistributables were messed up (I already had one installed, then Qt 5 installed one and at the same time there was this security update) although this shouldn't matter for MinGW-built applications. On the other hand, when the application crashed, it gave the classical "Microsoft Visual C++ Runtime Library. This application has requested the Runtime to terminate" message. Nevertheless, the application works even if there is no MSVC Redist installed.
Maybe I'll retry the Qt 5 port later with a clean system, i.e. uninstall everything again, reboot, install Qt 5 and then try again.
Thanks anyway for the information/help.
That's certainly odd. I'm glad you've pinpointed the issue.