Bump vcpkg to 2026.04.27#6015
Open
MaxRayskiy wants to merge 9 commits into
Open
Conversation
Fedr
added
skip-image-rebuild
In vcpkg 2026.04.27 the `zlib` port is now satisfied via `zlib-ng[compat]`, which produces `zlib-ng2.dll` (Release) and `zlib-ngd2.dll` (Debug) in `installed/<triplet>/bin/` and `debug/bin/`. The legacy `zlib1.dll` / `zlibd1.dll` filenames no longer exist. `MRIOExtras` (Debug post-build) and `MRPython` (CMake) both copy the Release zlib alongside Release-built consumers (OpenCTM, laz-perf, Python) so they can resolve their import library at runtime. With the old filename gone, the copy step failed with `MSB3073` and cascaded failures across the Debug MSBuild matrix on PR #6015. Update both copy paths to the new filename. The Debug variant is already deployed automatically by vcpkg's applocal step for Debug consumers.
Fedr
added
bump-vcpkg
and removed
skip-image-rebuild
The windows-build-test matrix already runs on windows-2022 (see .github/workflows/matrix/windows-*-config.json), but several other jobs still target windows-2025. That mismatch broke the Debug+MSBuild and Release+CMake builds on this PR: the vcpkg cache producer (prepare-image / windows-vcpkg-build-upload) ran on windows-2025 with a newer MSVC STL, while the consumer windows-build-test jobs ran on windows-2022 with an older STL. Static libs built into the vcpkg cache (notably fastmcpp_core.lib) then failed to link against the consumer's libcpmt.lib/libcpmtd.lib with LNK2019 on STL-internal helpers like __std_find_last_not_ch_pos_1 and __std_regex_transform_primary_char. Align every runner to windows-2022 so the producer's STL matches the consumer's. Affected jobs: - prepare-image / windows-vcpkg-build-upload (vs2022, vs2019, vs2019-itdbg) - build-test-distribute / create-nuget-package - test-distribution / windows-test - update-win-version / update-win-version After this commit, the existing PR-scoped cache entry (vcpkg-cache-2026.04.27-x64-windows-meshlib-715686af...-slim2) is still stale, since it was produced on windows-2025. Delete it (gh cache delete) so the next PR run re-populates it on windows-2022.
Fedr
added
full-ci
…4.27 # Conflicts: # source/MRIOExtras/MRIOExtras.vcxproj # source/MRPython/CMakeLists.txt
The existing diagnostic dumps `dumpbin /dependents` for only MeshViewer.exe, MRMesh.dll and MRTest.exe. When MRTest.exe exits at startup with no output (Windows load-time DLL failure), the missing DLL is almost always a transitive import of one of the other ~95 binaries deployed alongside, so the three-target dump can't pin it down. Extend the script to scan every *.dll / *.exe / *.pyd in CWD: for each, dump /dependents, then flag any imported DLL that is neither present in CWD nor a known Windows / VC redist / Python / CUDA / NVIDIA driver DLL. The original per-target dumps are kept so log diffs against earlier runs still work. On the next CI run for #6015, the diagnostic will name the binary whose import vcpkg 2026.04.27's applocal step failed to deploy — e.g. a Debug consumer still asking for xerces-c_3_3D.dll when only the Release xerces-c_3_3.dll was copied, or python312.dll still asking for zlib1.dll under the zlib-ng compat rename.
Fedr
added
skip-image-rebuild
Two follow-ups to the previous diagnostic extension: 1. Fix the cross-check no-op. `Get-ChildItem . -File -Include …` is a PowerShell footgun: without `-Recurse` or a wildcard in the path, `-Include` silently filters everything out, so the loop iterated over zero binaries on the last run (5 ms between the banner and the next section in the log). Switch to `.\*` so the include actually fires; also print the scanned count and the total flagged-import count so a no-op is obvious from the log header. 2. Dump imports for the Python-embedding DLLs, not just the original three. The last run showed Run-Start-and-Exit Tests (MeshViewer.exe) and Verify-meshlib.mrmeshpy-import (system py -3.12) both pass, while Unit Tests (MRTest.exe) exits 1 in ~320 ms with zero stdout. The unique thing MRTest exercises is the embedded Python: it directly imports MREmbeddedPython.dll / MRPython.dll / pybind11nonlimitedapi_stubs.dll, which load python312.dll + python3.dll. Dumping /dependents of those five gives us a direct read on whether the embedded Python's release-config zlib / openssl / sqlite dependency name is something applocal didn't deploy into the Debug runtime.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR updates the vcpkg tag to 2026.04.27