Update vcpkg to the 2026.07.29 release

[magnesj]

Moves the ThirdParty/vcpkg submodule from a353d2c04f to df31882c43, rebasing the fork-local patches onto microsoft/vcpkg tag 2026.07.29 (9e593bb18e) and adding one new patch for RHEL8.

Why

The previous submodule commit sat on upstream from January 2025, which pins msys2-runtime-3.5.4-2. MSYS2 prunes superseded package builds from its repos and that distfile is gone — every mirror returns 404. Any Windows build with a cold vcpkg binary cache therefore failed during configure, as soon as the first port needing pkgconf was built:

Downloading msys2-msys2-runtime-3.5.4-2-x86_64.pkg.tar.zst
error: https://mirror.msys2.org/msys/x86_64/msys2-runtime-3.5.4-2-x86_64.pkg.tar.zst: failed: status code 404
   ... same 404 on all six mirrors
CMake Error at scripts/cmake/vcpkg_download_distfile.cmake:231 (message): Download failed, halting portfile.
error: building rapidjson:x64-windows failed with: BUILD_FAILED

The call chain is rapidjson/portfile.cmake → vcpkg_fixup_pkgconfig → vcpkg_find_acquire_program(PKGCONFIG) → vcpkg_acquire_msys. rapidjson is only where it surfaced first; anything reaching vcpkg_acquire_msys would have hit it. Linux and macOS are unaffected because they use the system pkg-config.

A warm binary cache masked this — the affected ports were restored prebuilt and vcpkg_acquire_msys never ran. The cache key embeds the runner image version, so each new GitHub Windows image reintroduced the failure until a run happened to repopulate the cache from a branch that could read it.

The new base pins msys2-runtime-3.6.5-1, which is still hosted.

RHEL8 fallout, fixed in the second commit

The newer toolchain broke the RHEL8 job, which pins its own older ports baseline in vcpkg-configuration-rhel8.json for Rocky Linux 8 compatibility (glibc 2.28, OpenSSL 1.1). At that baseline arrow is 18.1.0, and its portfile passes -DCMAKE_SYSTEM_PROCESSOR=${VCPKG_TARGET_ARCHITECTURE} — that is x64, vcpkg's triplet name, not the GNU name x86_64:

-- Cross-compiling for target x64 (x64) on host  (x86_64).
CMake Error at CMakeLists.txt:103 (project):
  The CMAKE_C_COMPILER:  x64-linux-gnu-gcc
  is not a full path and was not found in the PATH.

The value is already in the cache when scripts/toolchains/linux.cmake runs, so its own non-FORCE set(CMAKE_SYSTEM_PROCESSOR x86_64 ...) cannot correct it. The cross-compilation check a few lines below then compares x64 against a host processor of x86_64, treats the native build as a cross build, and points CMAKE_C_COMPILER and friends at a x64-linux-gnu- prefix that does not exist. The January 2025 toolchain carried no such inference, so the mismatch used to be harmless.

The fourth fork patch normalizes the vcpkg architecture names to the GNU names ahead of that check. The default baseline never needed it: arrow is 21.0.0 there and no longer passes the flag, upstream having removed it in microsoft/vcpkg#47958. Bumping the RHEL8 baseline past that commit (2025-10-27) would also fix it, but that is a nine-month jump for a baseline deliberately held back for old-system compatibility.

Fork-local patches

All four live on CeetronSolutions/vcpkg branch no-debug-symbols-release-2026.07.29. The net diff against upstream is exactly:

• /Z7 removed from CMAKE_{C,CXX}_FLAGS_{DEBUG,RELEASE} in scripts/toolchains/windows.cmake
• CMAKE_POLICY_VERSION_MINIMUM=3.5 appended to triplets/x64-linux.cmake
• CMAKE_POLICY_VERSION_MINIMUM=3.5 appended to triplets/x64-windows.cmake
• vcpkg architecture names normalized to GNU names in scripts/toolchains/linux.cmake

Two of the original commits conflicted on scripts/toolchains/windows.cmake, which upstream has rewritten since. Resolved in favour of upstream's version with /Z7 stripped. Upstream independently dropped /D_DEBUG from the debug flags, so that half of "Remove debug symbols from debug build" is now redundant and no longer appears in the diff. triplets/x64-windows.cmake also conflicted because upstream added set(VCPKG_PROVIDED_FORTRAN ON); both lines are kept.

Scope

.gitmodules still points at CeetronSolutions/vcpkg, and the ports baseline in vcpkg-configuration.json stays at 84bab45d (2025-12-13) — this changes the vcpkg tool and its scripts/, not the port set. That leaves a deliberate skew: ports from December 2025 built by scripts from July 2026. Bumping the baseline to match the release is a separate, much larger change.

Verification

Bumping the submodule changes the vcpkg cache key, so every job ran cold and built all ports from source rather than restoring prebuilt ones. The Windows job reported No cache found and then reached the exact path that was failing:

Downloading msys2-msys2-runtime-3.6.5-1-x86_64.pkg.tar.zst, trying https://mirror.msys2.org/msys/x86_64/...
Successfully downloaded msys2-msys2-runtime-3.6.5-1-x86_64.pkg.tar.zst

RHEL8 rebuilds all 101 ports on every run regardless, and arrow 18.1.0 now configures with the container's own compiler. Both fixes are therefore exercised against the failures that motivated them. The long build times on this run are the one-off cost of the cold caches.