# Issues compiling against Qt6.9.0
**URL:** https://discourse.paraview.org/t/issues-compiling-against-qt6-9-0/17151
**Category:** ParaView Support
**Created:** [September 3, 2025, 9:41pm UTC](https://discourse.paraview.org/t/issues-compiling-against-qt6-9-0/17151 "2025-09-03T21:41:13Z")
**Posts on this page:** 17
**Page:** 1
### Author:  [@kvankooten](https://discourse.paraview.org/u/kvankooten)
#### Post date: [September 3, 2025, 9:41pm UTC](https://discourse.paraview.org/t/issues-compiling-against-qt6-9-0/17151/1 "2025-09-03T21:41:13Z")
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:
?dynamicMetaObject@QObjectData@@QEBAPEBUQMetaObject@@XZ
this symbol belongs to the implementation of
const QMetaObject \*QObjectData::dynamicMetaObject() const
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.
Cheers,
Kees
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [September 4, 2025, 2:03am UTC](https://discourse.paraview.org/t/issues-compiling-against-qt6-9-0/17151/2 "2025-09-04T02:03:59Z")
We use official Qt pre-compiled binaries, not anything we compile ourselves. You can get them with the Qt Installer.
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [September 4, 2025, 8:17am UTC](https://discourse.paraview.org/t/issues-compiling-against-qt6-9-0/17151/3 "2025-09-04T08:17:48Z")
> [@kvankooten](#):
>
> plugin against PV 6.0, in order to load that plugin with the official binary release on Windows and Linux.
This is not supported UNLESS you use something like the [https://gitlab.kitware.com/paraview/paraview-easy-plugin-builder](https://gitlab.kitware.com/paraview/paraview-easy-plugin-builder)
> 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.
Just use the pepb shared above instead 🙂
---
### Author:  [@kvankooten](https://discourse.paraview.org/u/kvankooten)
#### Post date: [September 4, 2025, 8:48am UTC](https://discourse.paraview.org/t/issues-compiling-against-qt6-9-0/17151/4 "2025-09-04T08:48:45Z")
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:
`dumpbin /EXPORTS Qt6Core.dll | find /I “dynamicMetaObject”`
`…`
`3355 D1A 00012850 ?dynamicMetaObject@QObjectData@@QEBAPEAUQMetaObject@@XZ `
`3356 D1B 00012850 ?dynamicMetaObject@QObjectData@@QEBAPEBUQMetaObject@@XZ `
`…`
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.
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [September 4, 2025, 8:52am UTC](https://discourse.paraview.org/t/issues-compiling-against-qt6-9-0/17151/5 "2025-09-04T08:52:07Z")
Here are the hashes of the Qt binaries we use: [https://gitlab.kitware.com/paraview/paraview-superbuild/-/blob/master/.gitlab/ci/download\_qt6\_hashes.cmake?ref\_type=heads](https://gitlab.kitware.com/paraview/paraview-superbuild/-/blob/master/.gitlab/ci/download_qt6_hashes.cmake?ref_type=heads)
---
### Author:  [@kvankooten](https://discourse.paraview.org/u/kvankooten)
#### Post date: [September 4, 2025, 8:52am UTC](https://discourse.paraview.org/t/issues-compiling-against-qt6-9-0/17151/6 "2025-09-04T08:52:12Z")
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?
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [September 4, 2025, 8:54am UTC](https://discourse.paraview.org/t/issues-compiling-against-qt6-9-0/17151/7 "2025-09-04T08:54:31Z")
> [@kvankooten](#):
>
> every library we depend upon.
Then rebuild ParaView instead of using the binary ? I’m not following.
> Out of interest, I’m not seeing support for Windows builds, or am I missing something?
Indeed, docker with Windows guest is not mature enough I’m afraid. We provide this instead:
[https://gitlab.kitware.com/paraview/paraview-plugin-windows-binary-compatible-guide](https://gitlab.kitware.com/paraview/paraview-plugin-windows-binary-compatible-guide)
---
### Author:  [@kvankooten](https://discourse.paraview.org/u/kvankooten)
#### Post date: [September 4, 2025, 9:00am UTC](https://discourse.paraview.org/t/issues-compiling-against-qt6-9-0/17151/8 "2025-09-04T09:00:46Z")
> [@mwestphal](#):
>
> Then rebuild ParaView instead of using the binary ? I’m not following.
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.
---
### Author:  [@kvankooten](https://discourse.paraview.org/u/kvankooten)
#### Post date: [September 4, 2025, 9:42am UTC](https://discourse.paraview.org/t/issues-compiling-against-qt6-9-0/17151/9 "2025-09-04T09:42:58Z")
> [@mwestphal](#):
>
> Here are the hashes of the Qt binaries we use: [https://gitlab.kitware.com/paraview/paraview-superbuild/-/blob/master/.gitlab/ci/download\_qt6\_hashes.cmake?ref\_type=heads](https://gitlab.kitware.com/paraview/paraview-superbuild/-/blob/master/.gitlab/ci/download_qt6_hashes.cmake?ref_type=heads)
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?
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [September 4, 2025, 11:22am UTC](https://discourse.paraview.org/t/issues-compiling-against-qt6-9-0/17151/10 "2025-09-04T11:22:25Z")
> [@kvankooten](#):
>
> 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.
That may be true for Qt, but that is not for ParaView.
> 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?
Thats a @ben.boeckel question
---
### Author:  [@kvankooten](https://discourse.paraview.org/u/kvankooten)
#### Post date: [September 4, 2025, 11:42am UTC](https://discourse.paraview.org/t/issues-compiling-against-qt6-9-0/17151/11 "2025-09-04T11:42:07Z")
> [@mwestphal](#):
>
> That may be true for Qt, but that is not for ParaView.
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 🙂
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [September 4, 2025, 1:15pm UTC](https://discourse.paraview.org/t/issues-compiling-against-qt6-9-0/17151/12 "2025-09-04T13:15:45Z")
> [@kvankooten](#):
>
> it should not be the case that two versions of Qt with exactly the same version number are not ABI compatible.
Build options can definitely make incompatible binaries.
> [@kvankooten](#):
>
> 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.
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.
> [@kvankooten](#):
>
> 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?
I believe that is the build date.
> [@kvankooten](#):
>
> 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?
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.
---
### Author:  [@kvankooten](https://discourse.paraview.org/u/kvankooten)
#### Post date: [September 4, 2025, 2:07pm UTC](https://discourse.paraview.org/t/issues-compiling-against-qt6-9-0/17151/13 "2025-09-04T14:07:45Z")
> [@ben.boeckel](#):
>
> Build options can definitely make incompatible binaries.
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.).
> [@ben.boeckel](#):
>
> I believe that is the build date.
> [@ben.boeckel](#):
>
> I believe that signing the package may interfere.
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.
---
### Author:  [@kvankooten](https://discourse.paraview.org/u/kvankooten)
#### Post date: [September 4, 2025, 2:43pm UTC](https://discourse.paraview.org/t/issues-compiling-against-qt6-9-0/17151/14 "2025-09-04T14:43:53Z")
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:
>
>
> It's semi-private API (ie. undocumented) and for most platforms¹, the
> change is …a no-op, which is why the approach here is a bit different
> than your usual REMOVED\_SINCE:
>
> Normally, when only the return value changes, we mark the new overload
> as QT6\_\*\_NEW\_OVERLOAD to allow the two function to coexist and the old
> function to call the new one.
>
> But the extra argument backing QT6\_\*\_NEW\_OVERLOAD would change the
> mangling of the function even on platforms that don't mangle the
> return type (the majority), and we'd have to decorate all calls that
> could possibly be seen by QtCore's removed\_api.cpp TU with
> QT6\_CALL\_NEW\_OVERLOAD. The main user of the API is moc-generated code,
> though, and so I didn't want to have to change moc's output, even
> though, currently, nothing in removed\_api.cpp includes moc-generated
> code. But it may, at some point in time.
>
> This means I needed to grasp the nettle and duplicate the (granted,
> trivial) implementation. Even a private helper function would mean
> (maintenance and runtime) overhead for "normal"¹ platforms, so I opted
> not to go there, either.
>
> ¹ those that (rightfully) don't mangle the return type, ie. all except
> ... MSVC.
>
> As a benefit, we catch the mistake of modifying the dynamic
> QMetaObject under the object's radar already now.
>
> \[ChangeLog\]\[Potentially Source-Incompatible Changes\]\[QtCore\]\[QObjectData\] This
> (undocumented) class' dynamicMetaObject() function now returns a const
> QMetaObject\* (was: non-const). The backwards-compatible fix is to
> receive the result in a const QMetaObject\* variable (or to use auto),
> and applying a manual const\_cast, if a non-const object pointer was
> actually required. Modifying the meta object that was returned by this
> function was never supported and may lead to problems elsewhere.
>
> Amends 0b044e8b055f9c1d93b278ed69aba76f7c886cb1.
>
> Change-Id: I4ebc43018a2a87433ab7a97554196842b97cf1ba
> Reviewed-by: Fabian Kosmale \
> Reviewed-by: Thiago Macieira \
> (cherry picked from commit 2c212e15f8b9dc2578d93ac69a0f5826ea9de18f)
> Reviewed-by: Qt Cherry-pick Bot \
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.
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [September 5, 2025, 8:26am UTC](https://discourse.paraview.org/t/issues-compiling-against-qt6-9-0/17151/15 "2025-09-05T08:26:35Z")
So I’ve downloaded the package we use and qobject.h looks like this:
```auto
#if QT_VERSION >= QT_VERSION_CHECK(7, 0, 0)
const QMetaObject *dynamicMetaObject() const;
#else
QMetaObject *dynamicMetaObject() const;
#endif
```
So it looks like you are right @kvankooten
@ben.boeckel wdyt ?
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [September 6, 2025, 1:20am UTC](https://discourse.paraview.org/t/issues-compiling-against-qt6-9-0/17151/16 "2025-09-06T01:20:36Z")
Indeed. The 6.9.0 binaries are already available; we just need to update dates and expected hashes to use them.
Note that VTK, ParaView, common-superbuild, and paraview-superbuild (at least) have Qt6 downloads in CI that would be good to update.
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [September 11, 2025, 2:23pm UTC](https://discourse.paraview.org/t/issues-compiling-against-qt6-9-0/17151/17 "2025-09-11T14:23:52Z")
@kvankooten this issue was fixed and your plugin should now load in the latest nighty and in the upcoming ParaView 6.9.1