I’m trying to compile a plugin against PV 6.0, in order to load that plugin with the official binary release on Windows and Linux. From inspection of the official binaries, PV6.0 is compiled against QT 6.9.0.
Compiling and running against a local PV/Qt build works fine, in fact the only issue is caused at runtime on Windows, where it seems like the QT6 binaries delivered with the official PV 6.0 build do not include a particular symbol:
which is a function introduced with Qt version 6.9.0.
Instead, the Qt6 binaries from the PV package only include a similar symbol originating from a non-const (older) Qt5 version of the same function, which can theoretically be forced to compile against using QT_CORE_BUILD_REMOVED_API for the plugin.
Somehow, the Kitware build of Qt completely eliminates the newer function implementation from the final binary, and I am not sure which flags/arguments are used to accomplish this. I tried to work around the issue by explicitly linking to the older non-const version of the function from Qt5 with the macro from above, but that introduces a host of other compilation issues.
Instead of making the solution more complicated, I wonder if it’s possible to get the build log of the Qt CI pipeline, or other information which could get me to match up the Qt symbols for the plugin with symbols in the distributed binaries.
I wonder if it’s possible to get the build log of the Qt CI pipeline, or other information which could get me to match up the Qt symbols for the plugin with symbols in the distributed binaries.
The msvc 2022 64-bit 6.9.0 binaries from the Qt installer are different from what is delivered with the official PV 6.0 release, so maybe there is a mistake? The size doesn’t match up, and the Qt version of the binaries do contain the necessary symbols:
I have the feeling that QtCore6.dll from the PV distribution is an old binary, but what is weird is that it is stamped with v6.9.0.0 in the library versioninfo section.
Regretfully I don’t have another choice, since as per company policy we need to provide source and internally build from that source every library we depend upon.
Out of interest, I’m not seeing support for Windows builds, or am I missing something?
The plugin has direct dependencies on Qt for the interface part, which if I compile those using the official Qt installer 6.9.0 package would lead to symbols being referenced which are included in the official Qt distribution binaries, but not in the PV binary package. Because I’m not redistributing the Qt library, I depend on the PV ones being ABI compatible, and that should be fine as long as we both compile against the same Qt version.
I will check out the binaries that result from the hashes, but the gist of it is that it should not be the case that two versions of Qt with exactly the same version number are not ABI compatible.
From what I can see these only reference kitware-internal packages, correct? It would be good to check those for consistency with the official Qt6 release.
Also, from the date stamp (20250117) it looks like the hash has been generated before Qt6.9.0 came out, so maybe it’s a beta version?
My experience there (since PV 5.4) has been rather positive; I haven’t yet had any issues using locally built PV source to compile ABI-compatible plugins - even if a problem pops up at some point, it is relatively easy to find the offending compile flag and adjust for it on my side. Therefore I have good hopes that with a matching Qt package (which would be necessary anyway for PV plugin development, since one has to build against his own Qt install), we’ll be in the clear again
Build options can definitely make incompatible binaries.
They are mirrored from Qt’s download locations. We rehost them so that CI machines are not pulling from nominally-requires-a-login-to-download as the official installer does in case Qt ever does lock them down. There are sha256 hashes in the .gitlab/ci/download_qt6_hashes.cmake file you can verify against.
I believe that is the build date.
I believe that signing the package may interfere. Or the install process is changing things around? In any case, we start with the official release binaries Qt provides and any modifications should just be metadata bits to make things redistribute cleanly.
Sure, but in this case we are talking about ‘the one’ official release of Qt 6.9.0 for win2022 64-bit, a binary package that doesn’t come in multiple flavors with build options as far as I’m aware. In fact, the client of Qt generally chooses the API using macros through its headers, with the binaries simply containing all possible function definitions, reducing ABI compatibility issues. So those same binaries have to be used both by the PV internal build and external parties building plugins for PV.
In summary, this has to be an ABI compatible package, otherwise it will not be possible for anybody to build plugins for PV that contain GUI elements, since you are required to use your own Qt install to build those - regardless of which mechanism is used (superbuild, plugin builder, etc.).
It’s more than metadata: there are symbols missing from QtCore (vs the official Qt binaries), and the build date is 2 months early, which is extremely suspicious. Either way, at this point compatibility with the official Qt 6.9.0 release is broken.
I made some progress in finding the likely cause, given that the particular function definition that is missing has been committed as of Jan 31, after the build date of the PV-internal Qt hash:
The first tag that it has been a part of is 6.9.0-beta3, which supports my suspicion that PV has been built with an earlier beta of Qt 6.9.0. Regretfully, I don’t know how to install past Qt betas to confirm this further, as they don’t seem to be available from the installer. Nevertheless, the best solution is to have a PV build based on the full release version of Qt 6.9.0.
