qt.qpa.plugin: Could not find the Qt platform plugin "windows" in "" error

When one attempts to open the GUI on "Windows OS", the message: qt.qpa.plugin: Could not find the Qt platform plugin "windows" in "" error pops up.

changed the description

To solve this issue:

• copy the folder "platforms" in "C:\msys64\mingw64\share\qt5\plugins", and paste it into "C:\OpenPASS\bin\core".

changed the description

mentioned in issue #203 (closed)

moved from opgui#5 (moved)

changed milestone to %Release v0.11

assigned to @jdobberstein

Additional ways to solve this issue:

1. Set the QT_PLUGIN_PATH environment variable to the path, where the qt plugins are stored
2. Provide a qt.conf file within the openPASS binary folder [Paths] Plugins=plugins
3. Hardcode the libary path into openPASS.cpp QCoreApplication::addLibraryPath("C:/msys64/mingw64/share/qt5/plugins");

Anyway, the cleanest way to solve this issue would be to use the windeployqt (https://doc.qt.io/qt-5/windows-deployment.html) to provide all qt related stuff within the binary folder. I have not analysed that solution in detail, but at the first look it seems like a greater change in the build process. Since the GUI is changing in the near future, I would go for one of the workarounds until the new GUI is in place.

I would prefer the qt.conf file solution. What are your opinions on this?

@rbiegel what do you think? How do the suggestions match with your approach here? https://gitlab.eclipse.org/eclipse/openpass/opSimulation/-/blob/main/cmake/install_deps.cmake

The mechanism used in install_deps.cmake won't work for libraries loaded at runtime (which I just assume the plugin folder is about because of its name).

Due to the fact that there is no further development of the Qt GUI planned, I'd also vote for the qt.conf solution.

Is it really that different from qt5core.dll, qt5xml.dll etc. which the CI also deploys as a zip file with artifacts at the end of each Windows build?

The other dlls that are copied are runtime dependencies, too - right?

Is it really that different from qt5core.dll, qt5xml.dll etc...

Assuming my assumption about the plugin folder containing real plugins is correct: yes

The install_deps.cmake mechanism can only resolve dependencies that are known at link time, i.e. libraries that would be shown by running ldd on an executable or library.

Contrary, the usage of plugins is not known at this point in time but rather determined by some kind of runtime configuration. Just as with the openPASS components: opSimulation doesn't link against a Sensor_OSI library at link time, but dynamically loads it because it is mentioned in some kind of a systemConfig file.

If my assumption from above isn't correct we could inject the plugin folder into the CMAKE_PREFIX_PATH. The install_deps.cmake would then pick up the required libraries from there.

I already tried to add it to the CMAKE_PREFIX_PATH, but this approach was not successful on my end, so that I only saw the suggested solutions

Provided a draft pull request !130 (merged) in case that the qt.conf file is the prefered solution until the new gui will be ready

mentioned in merge request !130 (merged)

Closed. Solved with !130 (merged).

closed