Dynamic linking problems with installed package including examples on Windows

[scheibel]

When installing glbinding, it ships with an own version of Qt.
If a user installs an own version of Qt (probably a newer one) and links its dependencies against glbinding, adjusts the %PATH% such that glbinding is found at runtime, it may happen that Windows chooses the shipped Qt of glbinding instead of the Qt the user wants to use for his/her application.

I think this may be fixed by moving the examples and Qt and GLFW libraries to an example subdirectory for the deployment.

[kateyy]

I noticed a related issue with Qt (platform) plugins in my applications: Executables linked to Qt contain the absolute path to the Qt installation that was used at build time (see https://doc.qt.io/qt-5/qcoreapplication.html#libraryPaths). When initializing a Q(Core)Application it will by default load platform plugins etc. from the original Qt installation path, if it exists on the target machine. Otherwise it will search in the application path (but not PATH or similar or the working directory). Thus the mechanism for loading Qt Libraries is completely different from loading Qt Plugins. This happens on Windows and Linux (and probably also on Mac).

So problem now is that different (minor) versions of Qt Libraries and Qt Plugins might be used at runtime, which might lead to application crashes if these versions are not compatible (such with 5.2.1/5.2.0 breaking binary compatibility). I have had this issue a few times when deploying my application and fixed by adjusting the Qt Library paths using a qt.conf file and manually setting the library paths.

This problem might not be relevant for glbinding itself, but with gloperate etc. it can cause problems when users are free to use their own Qt installations instead of the ones gloperate etc. were linked to.

[scheibel]

@kateyy You suggest to add qt.conf files for every Qt-based executable?

[kateyy]

I'd recommend a solution like that. Contrary to what you originally suggested, I use this solution to prevent the Qt application from using Qt libraries/plugins that are already installed on the target system. You can't check at application startup, if an installed Qt version on the target system is actually compatible to your linked Qt version.

PATH is used by windows to locate Qt libraries. But the path to Qt plugins is hardcoded into the QtCore library and is not influenced by PATH. So even if the user has an installed Qt version that is found in the PATH, the application will still use your deployed Qt plugins. Or even worse, it might use Qt plugins from a third location that incidentally matches the Qt location from the build machine.

So, you can use qt.conf to specify Qt plugin locations, which is the recommended solution (https://doc.qt.io/qt-5/windows-deployment.html, https://doc.qt.io/qt-5/linux-deployment.html). Or you use QCoreApplication::setLibraryPaths(), which is a bit hacky but doesn't require the qt.conf file. On Windows, you can also use windeployqt.exe which rewrites the plugin path in the deployed QtCore library (but I think it will also write absolute paths only).