[qtbase] Fix a few details

[Neumann-A]

• Fix control of cups dependency
• Fix binary and directory name collision in dynamic builds by not deploy plugins into tools/Qt6/bin (wasn't necessary in the first place due to qt.conf working as expected) (closes [qttools] Build error with qml option using x64-linux-dynamic triplet #28340)
• (New) Fix deploy script on windows (closes [qttools] Install error. #38936)
• Fix dbus linkage as described here [qtbase] Fix a few details #38682 (comment)
• Fix qtwebengine resource location to be in line what is stated in the generated qt.conf. There is probably a variable to control the installation location but moving was simpler then trying to find that variable. You will only notice it if you actually try to run a program using QtWebEngineProcess with the same qt.conf

[Neumann-A]

@tsondergaard: Anything more which needs fixing in qtbase?

[tsondergaard]

@tsondergaard: Anything more which needs fixing in qtbase?

I dunno, let me have a look around.... All I can spot are two oddities:

First issue

This first one is just a question: In qtbase/vcpkg.json I see this:

    {
      "name": "qtbase",
      "default-features": false,
      "features": [
        "doubleconversion"
      ]
    },

There is no "platform" property so if I am not mistaken this is an unconditional self-dependency with feature doubleconversion. What is the purpose of this? Is it a well-known pattern of some sort?

Second issue

The statements list(APPEND FEATURE_CORE_OPTIONS -DCMAKE_DISABLE_FIND_PACKAGE_PPS:BOOL=ON) and list(APPEND FEATURE_CORE_OPTIONS -DCMAKE_DISABLE_FIND_PACKAGE_Slog2:BOOL=ON) are duplicated. Probably not intended.

[dg0yt]

Anything more which needs fixing in qtbase?

Fix dbus installation order problems. Enforce "linked" on linux to match at-spi2-core (or similiar deps), and "runtime" everywhere else. Would unblock #38699.
Done for qt5-base in #38058.

[Neumann-A]

@data-queue: All the windows regressions here are due to adding cppwinrt to qtbase. So adding it is not really an option since it requires adding the vcpkg include folder to the default include folders (which should then be done by the cppwinrt port).

[equeim]

@data-queue: All the windows regressions here are due to adding cppwinrt to qtbase. So adding it is not really an option since it requires adding the vcpkg include folder to the default include folders (which should then be done by the cppwinrt port).

Another problem with cppwinrt port is that C++/WinRT has a link-time check that ensures that all object files in a binary were compiled with the same version of C++/WinRT. If some used one from Windows SDK and some from vcpkg then you will get linker error. This means that all ports that use C++/WinRT from Windows SDK internally (which is likely not easy to check) should be updated to depend on cppwinrt from vcpkg, otherwise it will create problems for users (and they will need to add dependency on cppwinrt in their apps too if they use C++/WinRT). IDK if this is a known problem in vcpkg, it just something I encountered personally.

[Neumann-A]

This means that all ports that use C++/WinRT from Windows SDK internally (which is likely not easy to check) should be updated to depend on cppwinrt from vcpkg, otherwise it will create problems for users (and they will need to add dependency on cppwinrt in their apps too if they use C++/WinRT)

The problem is that it is not enough to add the dependency. You actually need to setup the include and probably lib search directory ${VCPKG_INSTALLED_DIR}/(include|/(debug/)?lib) for that. Otherwise I wouldn't see the failures in cmake here since qtbase already pulls in cppwinrt here but the build itself has not setup the search directories. In the end it is a failure of the cppwinrt port not correctly overruling the VS installed version.

[BillyONeal]

We tried to discuss the cppwinrt issue today.

Problems:

• qt isn't finding cppwinrt from the cppwinrt port
  • (this was noted in the meeting but we didn't further discuss, I think the discussion below encompasses the fix)
• cppwinrt conflicts with the Windows SDK
  • @BillyONeal: I think we should consider removing cppwinrt given that it conflicts with the windows sdk
  • @data-queue: Neumann-A tried adding cppwinrt as a dependency and that didn't work because qt somehow didn't respond to the dependency
  • @ras0219: there should be a port selecting which cppwinrt to use. Even if that port ends up being blank
  • @BillyONeal: I didn't realize that the port was just grabbing a nuget package
  • @ras0219: I think we don't understand the situation; for example the actual dependency can be coming from one of qt's dependencies. I think that we need to actually have an understanding of where the thing is being used. Physically what files are being included where in order to determine the appropriate next steps. Independent of those next steps, if there are multiple supported implementations, there must be a port that selects the implementation, full-stop.
  • @data-queue: I agree that the long term fix is that anyone needing this depends on the port.
  • @AugP: I suppose we should talk with the owners of cppwinrt. But I'm concerned that they would say it implicates artifacts.
  • @ras0219: I don't think this implicates artifacts.
  • @ras0219: I found this message: Create vcpkg port cppwinrt#1 (comment)
  • @BillyONeal: I think this means we don't need to contact them before proceeding.
  • @AugP: Given that they support languages I can understand why they might go in the Windows SDK.
  • @BillyONeal: I note their repo says to use nuget though. So I withdraw my suggestion to deindex.

[BillyONeal]

Based on https://dev.azure.com/vcpkg/public/_build/results?buildId=102530&view=results

server.dir/manifest.res" failed (exit code 1319) with the following output:
ffmpegmediaplugind.lib(qffmpegwindowcapture_uwp.cpp.obj) : error LNK2038: mismatch detected for 'C++/WinRT version': value '2.0.240111.5' doesn't match value '2.0.220110.5' in Qt6Cored.lib(qlocale_win.cpp.obj)
vpx.lib(vp8_common_x86_subpixel_ssse3_asm.obj) : warning LNK4078: multiple '.rodata' sections found with different attributes (60500020)

Specifically, Qt6Cored.lib(qlocale_win.cpp.obj) looks like it needs to be built with the cppwinrt port.

[Neumann-A]

@BillyONeal: https://github.com/microsoft/vcpkg/runs/24854382133 is the CI run where cppwinrt is a dependency of Qt. Only static triplets fail. IT has error like:

qwindowsd.lib(qwindowsintegration.cpp.obj) : error LNK2038: mismatch detected for 'C++/WinRT version': value '2.0.220110.5' doesn't match value '2.0.240111.5' in Qt6Cored.lib(qlocale_win.cpp.obj)
qwindowsd.lib(qwindowscontext.cpp.obj) : error LNK2038: mismatch detected for 'C++/WinRT version': value '2.0.220110.5' doesn't match value '2.0.240111.5' in Qt6Cored.lib(qlocale_win.cpp.obj)
qwindowsd.lib(qwindowstheme.cpp.obj) : error LNK2038: mismatch detected for 'C++/WinRT version': value '2.0.220110.5' doesn't match value '2.0.240111.5' in Qt6Cored.lib(qlocale_win.cpp.obj)

The reason for these errors is easy to explain. Qt6Core has a lot of dependencies and one of those dependencies adds ${VCPKG_INSTALLED_DIR}/${TARGET_TRIPLET}/include to the include search paths. As soon as that include is added it will use and find the headers from the cppwinrt port. The qwindows plugin however does not depend on any other external dependencies (why should it? It assumes everything is provided by the winsdk which is correct) so it does not get any includes from vcpkg. As such it will use the VS installed headers and won't see the cppwinrt ports headers.

This is not only a problem for Qt but every downstream user which is not adding ${VCPKG_INSTALLED_DIR}/${TARGET_TRIPLET}/include as an include path.

[tsondergaard]

If I understand correctly this means the application will be linked with the system provided version of cups, as there is no cups port in vcpkg.git. In Qt 5 I believe cups is only linked into plugins/printsupport/libcupsprintersupport.so and it is probably the same in Qt 6. However, when libcupsprintersupport.so is loaded into the process it brings with it a bunch of shared libraries.

On RHEL 9.4 the distribution provided libcups.so pulls in an unpleasant amount of shared libraries:

# ldd /usr/lib64/libcups.so.2
        linux-vdso.so.1 (0x00007fffb9be8000)
        libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007fdef2c71000)
        libavahi-common.so.3 => /lib64/libavahi-common.so.3 (0x00007fdef2c63000)
        libavahi-client.so.3 => /lib64/libavahi-client.so.3 (0x00007fdef2c4e000)
        libgnutls.so.30 => /lib64/libgnutls.so.30 (0x00007fdef2a18000)
        libz.so.1 => /lib64/libz.so.1 (0x00007fdef29fe000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fdef2923000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fdef2718000)
        libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fdef263d000)
        libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fdef2624000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fdef261d000)
        libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007fdef260c000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fdef2605000)
        libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007fdef21d0000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fdef21bc000)
        libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007fdef2169000)
        libp11-kit.so.0 => /lib64/libp11-kit.so.0 (0x00007fdef1fd2000)
        libidn2.so.0 => /lib64/libidn2.so.0 (0x00007fdef1fb1000)
        libunistring.so.2 => /lib64/libunistring.so.2 (0x00007fdef1e2c000)
        libtasn1.so.6 => /lib64/libtasn1.so.6 (0x00007fdef1e12000)
        libnettle.so.8 => /lib64/libnettle.so.8 (0x00007fdef1dbb000)
        libhogweed.so.6 => /lib64/libhogweed.so.6 (0x00007fdef1d23000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fdef2d73000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fdef1cf6000)
        libsystemd.so.0 => /lib64/libsystemd.so.0 (0x00007fdef1c19000)
        libffi.so.8 => /lib64/libffi.so.8 (0x00007fdef1c0b000)
        libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007fdef1b6f000)
        libcap.so.2 => /lib64/libcap.so.2 (0x00007fdef1b65000)
        libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007fdef1a2c000)
        liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fdef1a00000)
        libzstd.so.1 => /lib64/libzstd.so.1 (0x00007fdef1929000)
        liblz4.so.1 => /lib64/liblz4.so.1 (0x00007fdef1903000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fdef18e8000)
        libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007fdef18c2000)

So a Qt application that dynamically loads the libcups.so.2 plugin will have two versions loaded of several of these libraries - one version from the system and one version from vcpkg. That sounds concerning to me.

[tsondergaard]

Changes look good to me. The CUPS support looks questionable to me, but the PR doesn't make it worse, it improves the situation by disabling CUPS in more situations and when it is enabled it should work as well as before.

[Neumann-A]

@FrankXie05 waiting for review

[BillyONeal]

Can you explain what specifically is being fixed here?

[Neumann-A]

@BillyONeal:

• Fix control of cups dependency
• Fix binary and directory name collision in dynamic builds by not deploy plugins into tools/Qt6/bin (wasn't necessary in the first place due to qt.conf working as expected) (closes [qttools] Build error with qml option using x64-linux-dynamic triplet #28340)
• (New) Fix deploy script on windows (closes [qttools] Install error. #38936)
• Fix dbus linkage as described here [qtbase] Fix a few details #38682 (comment)
• Fix qtwebengine resource location to be in line what is stated in the generated qt.conf. There is probably a variable to control the installation location but moving was simpler then trying to find that variable. You will only notice it if you actually try to run a program using QtWebEngineProcess with the same qt.conf