[qt] Update to 6.11.2 - #53469
[qt] Update to 6.11.2#53469
Conversation
e9f104a to
d762bcc
Compare
|
REGRESSION: kwindowsystem:x64-linux: I don't see how this could possibly have passed in previous CI runs (an installation order issue?) REGRESSION: qtmultimedia:*-android: It's either a bug in Qt's |
|
Current master for qtmultimedia[core,ffmpeg,qml,widgets]:x64-android so I would suggest to dive deeper instead of baseline. |
Is probably a bug introduced by Qt since the sources seems to get generated and then compiled. |
Do you also have logs for arm64-android? I wonder why is it in the
Yeah but I don't see any related changes. And since both |
qwayland-wayland.a is itself a plugin? KF6Windows should probably not build an *.so or not link the plugin |
It's an object file produced from the autogenerated |
|
I've reproduced the error locally but I don't see any differences in build process between 6.11.1 and 6.11.2. |
|
The commit that causes the regression is qt/qtbase@db5392c. kwindowmanager uses protocols from |
|
Alexander Neumann (@Neumann-A) any idea what might be wrong? |
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: |
|
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: 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) |
|
Hmm couldn't repro qtmultimedia failure locally with the following command: |
592acf3 to
a50f3fb
Compare
Billy O'Neal (BillyONeal)
left a comment
There was a problem hiding this comment.
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
|
Sorry, I tried :/. Will check again in the morning or if anything breaks go for it |
Head branch was pushed to by a user without write access
Billy O'Neal (BillyONeal)
left a comment
There was a problem hiding this comment.
Thanks! And yes, I put that patch back, I thought it was added here. Megaderp.
|
I wonder if bumping vcpkg-tool-nodejs would fix these random qtwebengine failures? |
I don't think they use that? |
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
https://www.qt.io/blog/qt-6.11.2-released
qt/qtbase@v6.11.1...v6.11.2