Skip to content

[qt] Update to 6.11.2 - #53469

Merged
Billy O'Neal (BillyONeal) merged 14 commits into
microsoft:masterfrom
Osyotr:qt-6.11.2
Sep 25, 2026
Merged

Billy O'Neal (BillyONeal) merged 14 commits into
microsoft:masterfrom
Osyotr:qt-6.11.2

Conversation

@Osyotr

Copy link
Copy Markdown
Contributor

@Osyotr

Osyotr (Osyotr) commented Aug 20, 2026 •

Copy link
Copy Markdown
Contributor Author

REGRESSION: kwindowsystem:x64-linux:

/usr/bin/ld: /mnt/vcpkg-ci/installed/x64-linux/debug/lib/libQt6WaylandClient.a(qwayland-wayland.cpp.o): in function `QtWayland::wl_registry::wl_registry(wl_registry*, unsigned int, int)':
/mnt/vcpkg-ci/b/qtbase/x64-linux-dbg/src/plugins/platforms/wayland/qwayland-wayland.cpp:21: multiple definition of `QtWayland::wl_registry::wl_registry(wl_registry*, unsigned int, int)'; src/platforms/wayland/CMakeFiles/KF6WindowSystemKWaylandPlugin.dir/qwayland-wayland.cpp.o:/mnt/vcpkg-ci/b/kwindowsystem/x64-linux-dbg/src/platforms/wayland/qwayland-wayland.cpp:20: first defined here

I don't see how this could possibly have passed in previous CI runs (an installation order issue?)

REGRESSION: qtmultimedia:*-android:

ld.lld: error: unable to find library -lxml2
ld.lld: error: unable to find library -licuuc

It's either a bug in Qt's FindFFmpeg.cmake which has some sketchy pkg-config parsing code, or a bug in ffmpeg exported pkg-config. Added arm-neon-android and x64-android to the ci.baseline.txt because arm64-android is already there.

@Neumann-A

Copy link
Copy Markdown
Contributor

Current master for qtmultimedia[core,ffmpeg,qml,widgets]:x64-android so I would suggest to dive deeper instead of baseline.

Installing 2011/2677 qtmultimedia[core,ffmpeg,qml,widgets]:x64-android@6.11.1...
qtmultimedia[core,ffmpeg,qml,widgets]:x64-android@6.11.1 package ABI: 37568c7fb233ac8d3108d41e15b74fa79f3fc3842eb404e2c7f1cd690b424baa
Building qtmultimedia[core,ffmpeg,qml,widgets]:x64-android@6.11.1...
-- Using cached qtmultimedia-everywhere-src-6.11.1.tar.xz
-- Extracting source /vcpkg/downloads/qtmultimedia-everywhere-src-6.11.1.tar.xz
-- Applying patch static_find_modules.patch
-- Applying patch remove-static-ssl-stub.patch
-- Applying patch fix-msvc-x86-propvariant.patch
-- Applying patch ffmpeg-devendor-signalsmith-stretch.patch
-- Applying patch ffmpeg.patch
-- Using source at /mnt/vcpkg-ci/b/qtmultimedia/src/here-src-6-e000c43898.clean
-- Note: qtmultimedia only supports dynamic library linkage. Building dynamic library.
-- Configuring x64-android
-- Building x64-android-dbg
-- Building x64-android-rel
-- Performing post-build validation
Starting submission of qtmultimedia[core,ffmpeg,qml,widgets]:x64-android@6.11.1 to 1 binary cache(s) in the background
Elapsed time to handle qtmultimedia:x64-android: 1.5 min

@Neumann-A

Copy link
Copy Markdown
Contributor

kwindowsystem:x64-linux:

Is probably a bug introduced by Qt since the sources seems to get generated and then compiled.

@Osyotr

Copy link
Copy Markdown
Contributor Author

Current master for qtmultimedia[core,ffmpeg,qml,widgets]:x64-android so I would suggest to dive deeper instead of baseline.

Do you also have logs for arm64-android? I wonder why is it in the ci.baseline.txt and others are not.

kwindowsystem:x64-linux: Is probably a bug introduced by Qt since the sources seems to get generated and then compiled.

Yeah but I don't see any related changes. And since both libQt6WaylandClient.a and KF6WindowSystemKWaylandPlugin.so try to link qwayland-wayland.a the only idea I have right now is that the linker was quietly ignoring one of the copies but doesn't do that anymore.

@Neumann-A

Copy link
Copy Markdown
Contributor

KF6WindowSystemKWaylandPlugin.so

qwayland-wayland.a is itself a plugin? KF6Windows should probably not build an *.so or not link the plugin

@Osyotr

Copy link
Copy Markdown
Contributor Author

@Osyotr

Copy link
Copy Markdown
Contributor Author

I've reproduced the error locally but I don't see any differences in build process between 6.11.1 and 6.11.2.

@Osyotr

Copy link
Copy Markdown
Contributor Author

The commit that causes the regression is qt/qtbase@db5392c.

kwindowmanager uses protocols from /usr/share/wayland/.
qtbase uses its own vendored copy of protocols in src/3rdparty/wayland/protocols/wayland/.
They are already quite different in 6.11.1 so I don't see why it would suddenly break after a minor change.

@Osyotr

Copy link
Copy Markdown
Contributor Author

Alexander Neumann (@Neumann-A) any idea what might be wrong?

@Neumann-A

Copy link
Copy Markdown
Contributor

In file included from /mnt/vcpkg-ci/b/kwindowsystem/src/v6.29.0-2c5cf145ff.clean/src/platforms/wayland/shm.cpp:8:
/mnt/vcpkg-ci/b/kwindowsystem/src/v6.29.0-2c5cf145ff.clean/src/platforms/wayland/shm.h:12:10: fatal error: qwayland-wayland.h: No such file or directory
12 | #include <qwayland-wayland.h>
| ^~~~~~~~~~~~~~~~~~~~
compilation terminated.

Looks just like a missing include. Locate the header, find the qt target to depend upon and simply link against it?

@Osyotr

Copy link
Copy Markdown
Contributor Author

Looks just like a missing include. Locate the header, find the qt target to depend upon and simply link against it?

It was my failed attempt to fix the issue, the real error is here:
https://dev.azure.com/vcpkg/public/_build/results?buildId=136342&view=logs&jobId=f79cfdd7-47a8-597f-8f57-dc3e21a8f2ad&j=f79cfdd7-47a8-597f-8f57-dc3e21a8f2ad

@ajtribick

Andrew Tribick (ajtribick) commented Sep 20, 2026 •

Copy link
Copy Markdown
Contributor

Seems that Wayland is rather hostile to static linking - the x64-linux-dynamic triplet works fine, presumably because the Wayland functions aren't marked for export, but static linking gives you nowhere to hide.

The qt6 ports install their version of the wayland.xml file to share/qt6/wayland/protocols/wayland/wayland.xml

Adding the following to the kwindowsystem portfile.cmake appears to fix the build:

vcpkg_replace_string(
    "${SOURCE_PATH}/src/platforms/wayland/CMakeLists.txt"
    "\${Wayland_DATADIR}/wayland.xml"
    "???/share/qt6/wayland/protocols/wayland/wayland.xml"
)

Not sure what ??? should be there (tested locally by just hardcoding the absolute path there), presumably there's some obvious CMake variable I can't find in the docs right now.

(This does feel somewhat hacky, probably the proper way to do things is to de-vendor the Wayland protocols, but this would also require the wayland port to install a known version of the wayland.xml protocol file even when X_VCPKG_FORCE_VCPKG_WAYLAND_LIBRARIES is not set)

@Osyotr

Copy link
Copy Markdown
Contributor Author

Hmm couldn't repro qtmultimedia failure locally with the following command:

./vcpkg install qtbase[core] qtbase[core,thread]:x64-linux-release qtmultimedia[core,ffmpeg] ffmpeg libsndfile[core] dbus[core]:x64-linux-release --triplet=x64-android --host-triplet=x64-linux-release

@BillyONeal Billy O'Neal (BillyONeal) left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the update!

Given that the existing ci.baseline.txt skip for arm64-android was here and the discussion suggests that the behavior may be nondeterministic I'm going to take this.

# Conflicts:
#	ports/qtbase/portfile.cmake
#	ports/qtbase/vcpkg.json
#	versions/baseline.json
#	versions/q-/qtbase.json
@BillyONeal

Copy link
Copy Markdown
Member

Sorry, I tried :/. Will check again in the morning or if anything breaks go for it

Comment thread ports/qtbase/portfile.cmake Outdated
auto-merge was automatically disabled September 23, 2026 08:24

Head branch was pushed to by a user without write access

@BillyONeal Billy O'Neal (BillyONeal) left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! And yes, I put that patch back, I thought it was added here. Megaderp.

@ajtribick

Copy link
Copy Markdown
Contributor

I wonder if bumping vcpkg-tool-nodejs would fix these random qtwebengine failures?

@BillyONeal

Copy link
Copy Markdown
Member

I wonder if bumping vcpkg-tool-nodejs would fix these random qtwebengine failures?

I don't think they use that?

@BillyONeal

Copy link
Copy Markdown
Member

/azp run

@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
Successfully started running 1 pipeline(s).

@BillyONeal
Billy O'Neal (BillyONeal) merged commit b08975f into microsoft:master Sep 25, 2026
16 checks passed
@Osyotr
Osyotr (Osyotr) deleted the qt-6.11.2 branch September 25, 2026 20:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants