[Solved, but not really understood] GUI applications ceased to work
koahnig last edited by koahnig
I have ended up in a strange situation on a windows 7 installation.
All applications are staored aside in a separate folder with all the required dlls and plugins as required. Basically I can copy the folder and place on another machine without fiddling around with the dependencies. Applications are in different folders and the dependencies are giving quite some redundancy which is not of concern with large disks nowadays. I used those directories to create with a non-Qt application single installation applications and so on.
Now I have started to use Qt installer framwork 2.0 and create the installation files with this framework. When testing the deployment on my development machine, the deployed do not work in the new folder. However, also in the original untouched folders the applications do throw the same error message.
Reboot of the machine did not help. Rebuild did not help. Starting through Qt creator did not help.
I have tried quite a couple things already without success. Only GUI applications are not working anymore. Console application still work from the very same folder without issues.
All application are based on Qt 5.3 and dlls and plugins are consistent with this version. When using the "faulty" installation file on my laptop, all works fine. Therefore, it is actually not the deployment or files used, but the problem shall have its origin on my development machine.
With the installer framework I had installed Qt 5.4, but not used yet. Also I ran an update run with the maintenance tool for Qt. However, I do not think that this shall have any effect since all the application and their dependencies are separate.
I had recently also a blue screen on my machine. This could be eventually the cause.
Pressing ok brings up
I am using actually MinGW for my applications.
The question is now what are the relevant .dlls from windows which have to be checked?
koahnig last edited by
I got it back to work.
I had tested a complete build with rebuild and all the whistles we typically tell others in unclear situations. However, I am using DESTDIR to divert the build to the separate folder. I occurred to me that independend check was not as independend as thought because of DESTDIR.
Commenting DESTDIR and doing rerun qmake and rebuild generated a new exe which I could suddenly start. This provided the lead to what to check.
I have found that the dlls in my separate folder had different time tags when comparing to one in Qt 5.3 folder. Assembiling a new folder with all the currently available dlls and plugins generated also startable GUI apps.
Presumably starting the update functionality in the QT Maintenance updated the Qt 5.3 dlls in the Qt folder which makes sense. And all new compilations shall work only with consistent libs and dlls.
However, that does not explain why I had problems as described above.
- I had a workable solution in a folder separate from Qt folder. I could not find a change in this separate folder which can be traced to the Maintenance run or anything else.
- When taking an application from those folders (I wasted space with a lot of redundancies) the assembly with Qt installer framework did not work on my machine.
- Test all other Qt GUI applications which are again separate did not work until I have updated the dlls.
- Using the very same installation application file and installed on a different machine the GUI was working. Conclusion is that it is not a problem with the installer application.
- Finally I have rebuild with DESTDIR again. The dlls had been updated in the meantime. All was working.
- Even untouched applications (not recompiled yet, not working prior to dll update) have no problems anymore.
- Final check has been using the new installer application on laptop. No mismatch and the freshly installed application can be started without a flaw.
Conclusion I have a solution for my problem. I still do not know what really went wrong and why. It must have something to do with inconsistent dlls. That is all I know.
Did you have an update to MinGW happening ?
koahnig last edited by koahnig
Yes, the new MinGW version has been installed as well.
However, it should have no influence at all. I have never done a compilation with the newer compiler nor did I change to Qt 5.4. I am still using the previous MinGW compiler and Qt 5.3.1 (but updated through maintenance tool).
The separate folders did not change, neither the dlls and plugins nor my own exes. Basically the upmost folder is holding quite a number of exes and all required dlls and plugins.
It is loaden with some history and actually a bit of mess also. At some point I had started to collect my exes there in a transferable way for collection and transfer to another machine. There are still "old" (at least a couple of month) exes. They did not work either.
Later I started to realize that this is not good when creating an installer (start out with a non-Qt install application). Taking the messy route I had sub-folder where I hold separate folders again. Each folder holds what is required as input for an installer application to be bundled. This creates redundant copies of the exe as well as of the dlls and plugins.
As stated above, I consider it as a big mess which required cleanup. However, suddenly the redundancy came in quite handy, because an accidential change of one file is always possible. However, changing all redundant copies has a likelihood of zero. GUI applications could not be started in any of the folders. Console applications could be started.
The only explanation I have is that there occured also a change in windows system folder related to the GUI stuff. The change is compatible with the updated dlls, but not with the older dlls. Alternatively, it may be a change in the registry through starting of dlls.
However, I have to admit I do not really believe either explanation.
The good thing is that the old assembly and the new assembly is working on another PC and also on windows servers.
I was thinking about an update to the dependencies from MinGW but indeed, it doesn't look like it happened.