Problem Deploying Qt5 Application to a Windows 8 platform

[davethomaspilot]

I've building an application a windows 7 platform using VS2010 with a qt5 plugin.

I deployed to windows 7 tablet machine quite a while ago. The executable and required qt5 dlls are in a directory structure that worked for the windows 7 tablet machine.

I tried copying this directory to the new Windows 8 (tablet) machine.

I had to set QT_QPA_PLATFORM_PLUGIN_PATH to get past the first complaint on the new platform. Now, the application just quits silently, probably due to some missing dependency.

I tried running the old dependency walker in profile mode. I get this message:

Second chance exception 0xE06D7363 (Microsoft C++ Exception) occurred in "KERNELBASE.DLL" at address 0x756DF896.

In static mode, the dependency walker complains about missing API-MS-WIN-CORE- dlls, but I've read that these aren't valid and should be ignored.

I recall very similar symptoms when I deployed to the Windows 7 machine that were solved by installing the VS2010 redistributable package. When I try installing the redist package on the new windows 8 platform, a message says a newer version is already installed.

How do I debug this issue? Do I need the older version of the redist package to run, since those are the dlls I linked the application against? Or, do I need to install qt5 on the target platform instead of just bringing along the dlls that were sufficient for the Windows 7 tablet?

[d_stranz]

The problem might be in the manifest files. We've run into severe headaches with differences in VC redist differences. We've had to manually edit manifest files and ensure the executable uses the redist versions found on the installed machine. Take a look at this. (https://msdn.microsoft.com/en-us/library/cc664727%28v=vs.90%29.aspx) Might hold the solution for you.

[davethomaspilot]

Thanks for the reply!

I think I want the default behavior-- bound to the original release version of libraries since I have a copy of all the needed Qt dlls and a mysql dll in the same directory as the executable, and that directory in in the system path.

One thing may be a clue. When I deployed to a Windows 7 platform, I did not need to set QT_QPA_PLATFORM_PLUGIN_PATH. But on the new windows 8 platform I do, else I get a complaint about not being able to find the windows platform.

read your reply more carefully...Are you saying later releases of, say, vs2010 redistributable are NOT compatible with code linked to a previous version?

Added after 28 minutes:

I don't know why I have to set a variable at all, since I thnk my directory structure is the default-- plugin/platforms/qwindows.dll with the plugin directory in the same directory as the executable.

But, if instead of using QT_QPA_PLATFORM_PLUGIN_PATH I use QT_PLUGIN_PATH=plugins, the problem is eliminated!

Does this make sense to anyone?

Thanks

Dave Thomas

[d_stranz]

You don't need to set an environment variable - you can do it in code in your app. See QCoreApplication::​addLibraryPath().