[qtbase] qtbase's `vulkan` feature ships a broken vendored Vulkan loader that breaks app startup

[kelteseth]

Is your feature request related to a problem? Please describe.

Note: This issue was verified by me and with help of Claude (see claude summary below). This issue was affecting our real world Qt6 app since we switched from prebuild Qt bins to vcpkg.

Vcpkg's qtbase[vulkan] feature pulls in the full vulkan port, which
bundles a copy of the Vulkan loader (libvulkan.so on Linux, vulkan-1.dll on Windows) next
to our executable. That loader shouldn't ship with the app at all — the Vulkan loader belongs
to the system. On Windows it comes with the GPU driver (that's why the Windows Vulkan SDK
ships vulkan-1.lib to link against but no vulkan-1.dll); on Linux it comes from a distro
package like libvulkan1 (Ubuntu) or vulkan-icd-loader (Arch). Qt only needs the Vulkan
headers to build, because it dlopens the loader at runtime instead of linking it — so
vulkan-headers is the right dependency, not vulkan.

On Windows the bundled loader happens to work, so nobody notices. On Linux it doesn't: the
vendored loader is built without the WSI surface backends (wayland/xcb/xlib), so it has no
working surface support. If it lands on the runtime search path it shadows the real system
loader, and the app crashes on startup with Failed to find vkCreateWaylandSurfaceKHR — even
though vulkaninfo shows the system loader supports it fine. Deleting the vendored .so
fixes it instantly.

Proposed solution

// ports/qtbase/vcpkg.json
"vulkan": {
  "dependencies": [
    { "name": "qtbase", "default-features": false, "features": ["gui"] },
-   "vulkan"
+   "vulkan-headers"
  ]
}

Describe alternatives you've considered

Instead of dropping the vendored loader, you could keep depending on vulkan-loader and just
enable its xcb/xlib/wayland features — that also produces a working libvulkan.so with the
missing surface functions. This is what we did first. Windows never needed this because its
Win32 WSI support isn't gated behind an opt-in feature like Linux's is (see below), so the
vendored loader always worked there.

Still worse than vulkan-headers: you're building and shipping a redundant copy of the loader
that duplicates what the OS/GPU driver already installs, with the same shadowing risk if it ever
drifts from what the real driver stack expects (new extensions, validation/overlay layers, etc.)
— just a working duplicate instead of a broken one.

Additional context

Claude summary — the detailed writeup for the issue body:

qtbase's vulkan feature ships a broken vendored Vulkan loader that breaks app startup

Building qtbase[vulkan] silently ships a libvulkan.so with no working surface support. If it
ends up on the runtime search path (common vcpkg deployment pattern), the app fails to create a
Vulkan surface at all — on X11 or Wayland — and never starts.

Root cause: Qt never links libvulkan, it dlopens it at runtime via QLibrary
(qbasicvulkanplatforminstance.cpp:46-73).
So depending on the vulkan stub port (headers + loader) instead of just vulkan-headers builds
a loader nobody links against. volk already got this exact fix in #25762.

Worse than just wasted build time: the vendored loader's WSI backends (xcb/wayland/xlib) are off
by default, so if it lands on the runtime search path it silently shadows the real system loader.
Hit this for real — got Failed to find vkCreateWaylandSurfaceKHR even though vulkaninfo showed
the system loader supports it fine. Deleting the vendored .so fixed it instantly.

Refs

• volk's vcpkg.json / #25762 — same fix, already done there
• qxcbvulkaninstance.cpp:16 — xcb plugin's loadVulkanLibrary call site
• ports/vulkan-loader/vcpkg.json — WSI features are opt-in, none on by default