2

I know there are several answers reagarding this problem with Qt (like this one Qt 5.1.1: Application failed to start because platform plugin "windows" is missing). I'm using Qt 5, but it seems this problem is also in other versions.

The accepted answer was not my problem, but following the links the solution to copy the platforms directory to the executable works fine. However I find this solution quite unsatisfactory, because it means that I have to distribute this same directory all over the place. In the project I have to copy it into the Debug/Release branches for EACH AND EVERY project that I create. Running designer.exe I also have this problem, so I have to copy it there as well, and so on.

Putting the plugin directory from my QT installation directory into the PATH didn't solve the problem, though I don't really understand why. Apparently there is some custom code loading the required plugin DLLs.

So I wonder if there is not some acceptable way of doing this properly, like setting a QT_HOME variable or similar, so I don't have to copy the DLLs all over the place.

Community
  • 1
  • 1
Devolus
  • 21,661
  • 13
  • 66
  • 113
  • Have you tried to link your program statically? – Massa Apr 04 '14 at 18:54
  • The DLLs from the `plugin/platform` directory don't seem to exist as static versions. – Devolus Apr 04 '14 at 19:04
  • You have to recompile your Qt to generate the static version of the libs. Ah, and I can't (currently) generate the MySQL connector, altough the Oracle one is working Ok. – Massa Apr 04 '14 at 19:08
  • I built QT myself using the opensource package. As I understood it, the static version should be builkt by default as well, or do I have to reconfigure? – Devolus Apr 04 '14 at 19:19
  • No, you have to reconfigure! See if [this](http://qt-project.org/wiki/How-to-build-a-static-Qt-for-Windows-MinGW) helps! – Massa Apr 04 '14 at 19:20
  • With a statically linked copy of Qt, plugins are linked into the executable. You **do** need to build the static Qt yourself. Qt distributions don't include a static build, and unless your build was configured as `-static`, it won't be static. – Kuba hasn't forgotten Monica Apr 04 '14 at 21:32
  • @LaszloPapp, is there another way to not copy the same DLLs all over the place, which kind of defeats the purpose of using a DLL in the first place. – Devolus Apr 04 '14 at 22:28
  • 1
    Possible duplicate of [Qt5 Static Build yields Failed to load platform plugin "windows"](http://stackoverflow.com/questions/16773789/qt5-static-build-yields-failed-to-load-platform-plugin-windows) – Jim G. Oct 30 '16 at 13:10

2 Answers2

0

Try to use QCoreApplication::addLibraryPath(PATH TO PLUGIN FOLDER).

OnWhenReady
  • 939
  • 6
  • 15
0

It is a bad idea to build Qt yourself in general, and in this case, it is not even warranted to have a static build. You have several ways to solve this issue:

From the documentation:

All Qt programs automatically support the following command line options:
\list

    \li \c{-platform} \e {platformName[:options]}, specifies the
        \l{Qt Platform Abstraction} (QPA) plugin.

        Overridden by the \c QT_QPA_PLATFORM environment variable.
    \li \c{-platformpluginpath} \e path, specifies the path to platform
        plugins.

        Overridden by the \c QT_QPA_PLATFORM_PLUGIN_PATH environment
        variable.

and

void QCoreApplication::addLibraryPath(const QString & path) [static]

Prepends path to the beginning of the library path list, ensuring that it is searched for libraries first. If path is empty or already in the path list, the path list is not changed.

The default path list consists of a single entry, the installation directory for plugins. The default installation directory for plugins is INSTALL/plugins, where INSTALL is the directory where Qt was installed.

See also removeLibraryPath(), libraryPaths(), and setLibraryPaths().

Depending on your exact desire, this could be solved one way or another like that.

László Papp
  • 51,870
  • 39
  • 111
  • 135
  • 3
    "It is a bad idea to build Qt yourself in general" I strongly disagree. That's the whole point of Qt: you have full control over what you ship with your application, and you can configure it according to your needs. I don't quite know what it means for something to be "not warranted" to have a static build. It's a supported configuration option. For deployment I haven't been using anything but static builds for over a year now, and I fail to see what's the issue. With aggressive optimization it provides binaries that use up less virtual memory, load faster, and run faster. It's a win-win. – Kuba hasn't forgotten Monica Apr 06 '14 at 06:07
  • There is simply no any point in building Qt yourself in a generic case since there are binaries. Moreover, static build is a _wrong_ idea IMHO just for the sake of using plugins. It will work just fine with the official builds. In fact, it would also be unacceptable to use Qt statically on embedded, etc, where you need to be concerned about the flash size, but then again, this is a different track than using plugins. Static build is not warranted for plugin loading. – László Papp Apr 06 '14 at 06:14
  • @LaszloPapp, If the plugins are really used in a shared way, I agree, that it is better to use them. I have to verify your solution to see if this was the problem. I moved my QT to a different directory and it seems it remembers the install prefix, so it might be the reason why it doesn't find the plugins except in the local path. I don't agree with the "bad idea to build myself" because this is IMO the point of an Open Source project. To be able to do this. ;) – Devolus Apr 06 '14 at 07:55