0

We are developing a Windows program using Qt.

I've recently installed Qt 5.15.0 on one of the development machines. On that machine, if I run my tests against Qt 5.11.3, they run fine. However, if I try to run against 5.15.0, they will not run. All the tests I have tried display this error dialog:

Screenshot of test_tvstringlist.exe error dialog

and a similar dialog about Qt5Testd.dll.

Running against 5.11.3, I have, amongst other directories, C:\Qt\5.11.3\mingw53_32\bin in my path. This directory contains, amongst other files, Qt5Core.dll, Qt5Cored.dll, Qt5Test.dll and Qt5Testd.dll.

Running against 5.15.0, C:\Qt\5.15.0\mingw81_32\bin lies on my path. That directory includes Qt5Core.dll and Qt5Test.dll, but neither Qt5Cored.dll nor Qt5Testd.dll.

[I have found this question which I suspect relates to the same issue. In view of the rephrasing and additional detail, I hope you will forgive the duplication.]

Update

Both the 5.11.3 and the 5.15.0 images were built by adding the appropriate directories to PATH (either C:\Qt\5.11.3\mingw53_32\bin and C:\Qt\Tools\mingw530_32 or ...\5.15.0\mingw81_32\... and ...\mingw810_32\...) and then executing

qmake <project.pro> -r CONFIG+=debug
mingw32-make

What do I need to do differently to be able to run the tests?

nurdglaw
  • 2,107
  • 19
  • 37

1 Answers1

0

I dont think binaries built with MinGW 8 are binary compatible with binaries built with MinGW 5. Your application and Qt libraries must be built with same compiler.

mugiseyebrows
  • 4,138
  • 1
  • 14
  • 15
  • I'm running different binaries, built with the appropriate compiler in each case - running against 5.11.3 I've compiled with the gcc in C:\Qt\5.11.3\mingw530_32 and I used the compiler in ...mingw810_32 to run against 5.15.0. – nurdglaw Dec 24 '20 at 16:08
  • :blush: It turns out that this was almost certainly the cause of my problem. Running interactively from Qt Creator, the build directory (by default) has the release built into its name, so after switching releases, you will automatically do a clean build, even if you don't have a release-specific build directory, it's likely that you would automatically try a clean build if faced by this kind of problem. On the development machine in question, with scripted builds, the build directory was shared between releases. A manual `rm -rf build` fixed the problem. – nurdglaw Dec 29 '20 at 09:07