Deploying a Qt 5 Gui application on Windows

napajejenunedk0

After reading "the official Qt 5 Windows application deployment guidelines":http://qt-project.org/doc/qt-5.0/qtdoc/deployment-windows.html, and after testing, I've come up with the following questions when deploying a Qt 5 Gui application:

The guidelines say that the QT5_INSTALL_DIR_PATH/plugins/platforms/qwindows.dll should be copied in a subdirectory named "platforms" which should be created at the same directory level as the application's executable:
App.exe
platforms/qwindows.dll

Let's start clean. Consider an application that depends on the core, gui and widgets Qt modules. After building a debug version of the application I've started it from Windows Explorer. I was given an error message several times complaining about missing dlls. I've copied them all:
Qt5Cored.dll
Qt5Guid.dll
Qt5Widgetsd.dll

icudt49d.dll
icuin49d.dll
icuuc49d.dll

libGLESv2d.dll
D3DCompiler_43.dll

After copying only these, depending on the compiler used to build the application: MSVC or GCC, you will get the following errors when trying to start the application:
GCC: unknown error (its description doesn't say anything informative about the source of the problem)
MSVC: Failed to load platform plugin "windows". Available platforms are:
minimal
windows

Let's consider the MSVC case. If you copy the whole "platforms" directory from the Qt 5 plugins directory and paste it in the application executable's directory, you will get the same error but with somehow "doubled" output:
MSVC: Failed to load platform plugin "windows". Available platforms are:
minimal
windows
minimal
windows

Now, running Dependency Walker on the qwindowsd.dll, what becomes obvious is that it depends on libEGLd.dll.
After copying it to the application's folder the application is run without runtime errors.

Now remove the "platforms" directory from the application's directory. The application is again ran without runtime errors.
So, my first question is:

When it is mandatory to deploy the platform plugins along with our application's executable in a "platforms" subdirectory?
Is the minimal platform plugin required only by GCC ( part of MinGW - minimalist )?

And a more general question:

How to decide which plugins to deploy depending on the selected Qt modules to link against?

For now, I know I have to deploy the sqldrivers plugin if QT += sql.
The officia Qt 5 Windows application deployment guidelines say that:

bq. If you are deploying an application that uses QtWebKit to display HTML pages from the World Wide Web, you should include all text codec plugins to support as many HTML encodings possible.

I don't see any textcodec plugins in the "plugins" directory of the Qt 5 installation.

So, since the plugins are dynamically loaded and Dependency Walker cannot resolve such dependencies (it has an option but it is said to work in some scenarios), then what is the deployment policy of the Qt 5 plugins e.g. when an application/dynamic library links agains a given Qt module, which corresponding plugins should be deployed as well?

lgeyer

http://qt-project.org/forums/viewthread/23891/#110679

You will always have to deploy at least one (for instance windows) platform plugin.

Arsene

Thaaaanks, this post was really helpful. I'm newbie to Qt and i needed almost a week to get from installation to deploying, too many threads on the same issues with way too many different solutions.
i hope it doesn't get harder from now on^^

kkoehne

Dependency Walker has a 'Profile' option, which works perfectly for me to get runtime (plugin) dependencies, too.

sl.sy.ifm

oh, nice hint ... I'm using the tool for so many years now, but haven't recognized the Profile-menu (probably because it only appears after loading a binary)

interesting ... custom-plugins (loaded via QtCore utilities) also appear under QtCore ... not at the binary that really uses them

windyweather

I know I'm coming late to the party here. But why don't we make a "redist" installable that will take care of all this stuff for any number of QT apps that might run on a desktop rather than having every program carry along the long and growing list of DLLs required to make it work?

I built installers back in the heady days of Qt 4.x and it was no where nearly so cumbersome. But now there are about twice as many DLLs as there used to be.

Sure, sure, flexibility is all well and good. And if you are building a boat load of apps that work together to make a system, no problem. The problem of all these DLLs is no problem compared with the problem of the larger system.

But come on guys... I'm building a little app to solve a little problem.
For some novices to use. Can't we make it easy for me and my customers to install and run this thing?

Thanks for considering the man on the street.

ww

starfire151

I'm a newbie to using this environment, also, but I wholeheartedly agree with windyweather.

I'm just trying to develop some simple applications (developed on a Windows 7 machine) that run on Windows 7 targets. While the program can compile and execute in the Qt environment cleanly, it seems to take a lot of effort to get it to run "standalone" on a different machine (or even the same machine outside of the Qt environment).

When I tried to execute the TextFinder.exe program (from the tutorial examples), it stated "Qt5Widgets.dll is missing". I downloaded the file and put it in the directory with the TextFinder.exe release version and tried it again. I got the "Qt5gui.dll is missing" error. I put that file in the TextFinder.exe release directory and tried it again... yup... yet another missing .dll. This time it's libGLESv2.dll. When does it end? I continued with adding libGLESv2.dll, then qt5core.dll, then mozglue.dll, then I finally gave up... It seemed like a fighting a losing battle...

starfire151

I'm a newbie to using this environment, also, but I wholeheartedly agree with windyweather.

I'm just trying to develop some simple applications (developed on a Windows 7 machine) that run on Windows 7 targets. While the program can compile and execute in the Qt environment cleanly, it seems to take a lot of effort to get it to run "standalone" on a different machine (or even the same machine outside of the Qt environment).

When I tried to execute the TextFinder.exe program (from the tutorial examples), it stated "Qt5Widgets.dll is missing". I downloaded the file and put it in the directory with the TextFinder.exe release version and tried it again. I got the "Qt5gui.dll is missing" error. I put that file in the TextFinder.exe release directory and tried it again... yup... yet another missing .dll. This time it's libGLESv2.dll. When does it end? I continued with adding libGLESv2.dll, then qt5core.dll, then mozglue.dll, then I finally gave up... It seemed like a fighting a losing battle...

SGaist

Hi,

That's why there's this fine wiki "entry":http://qt-project.org/wiki/Deploy_an_Application_on_Windows to help deployment besides the official Deployment Guide.

SGaist

Hi,

That's why there's this fine wiki "entry":http://qt-project.org/wiki/Deploy_an_Application_on_Windows to help deployment besides the official Deployment Guide.

starfire151

Thanks.

The wiki describes C:\Qt\5.2.1\mingw48_32\ as the path to the dynamically linked copy of Qt. Since I'm using msvc2013, am I correct in thinking this path should be C:\Qt\Qt5.3.2\5.3\msvc2013_opengl\bin? That's where all the .dll files appear to be located.

...This seems like a LOT of steps to go through just to run outside of the Qt environment...

starfire151

Thanks.

The wiki describes C:\Qt\5.2.1\mingw48_32\ as the path to the dynamically linked copy of Qt. Since I'm using msvc2013, am I correct in thinking this path should be C:\Qt\Qt5.3.2\5.3\msvc2013_opengl\bin? That's where all the .dll files appear to be located.

...This seems like a LOT of steps to go through just to run outside of the Qt environment...

SGaist

Indeed, you have to adapt it to your current Qt installation.

A bit more complicated because of the plugin handle, yes, however you would need to do the same for any 3rd party library you'd use when writing software.

SGaist

Indeed, you have to adapt it to your current Qt installation.

A bit more complicated because of the plugin handle, yes, however you would need to do the same for any 3rd party library you'd use when writing software.