Make the shipped package resolve its own zlib

[cb1kenobi]

⊙ Problem

Both windows-x64 targets failed in run 37962402212. The #29 generator fix worked — the log reaches Building the probe with Visual Studio 18 2026 and detects MSVC 19.51 — and the run stops one step later:

Could NOT find ZLIB (missing: ZLIB_LIBRARY) (found version "1.3.2")
  .../extracted/share/rocksdb/RocksDBConfig.cmake:52 (find_dependency)

RocksDBConfig resolves ZLIB in module mode, and vcpkg installs the static zlib as zs.lib — a name FindZLIB searches only inside its ZLIB_USE_STATIC_LIBS branch. Unix passed because z is in the default list and matches libz.a.

This is a defect in what we ship, not in the probe. find_package(RocksDB CONFIG) has never worked on Windows for any consumer of these archives. It went unnoticed because nothing exercised it until the probe existed. All four published Windows archives of v11.8.1 carry zs.lib.

💡 Solution

The first version of this fix set ZLIB_USE_STATIC_LIBS in the probe. Review rejected it: that repairs the one thing that tests the archive and leaves every other consumer broken, so the probe would no longer detect the defect.

The overlay portfile now patches the installed RocksDBConfig.cmake to name its own zlib, which is what vcpkg's own zlib wrapper does and needs no particular CMake version. The probe is a plain consumer again.

Two corrections beyond the wrapper's shape, each from a confirmed finding:

• The prefix comes from the config's own location. PACKAGE_PREFIX_DIR is reset by every config file, so the Snappy, lz4 and zstd dependencies imported above leave it holding one of theirs on CMake 3.29 and older.
• find_dependency(ZLIB **MODULE**), because RocksDBTargets links ZLIB::ZLIB and only FindZLIB defines it — the zlib package installed beside it exports ZLIB::ZLIBSTATIC. Without MODULE, a consumer preferring config mode configures and then fails to link.

🔧 Changes

File	What changed
vcpkg-overlays/rocksdb/portfile.cmake	After vcpkg_cmake_config_fixup, inject an archive-pinned zlib lookup ahead of find_dependency, deriving the prefix from the config's own directory and forcing module mode. A missing anchor is fatal at build time, so an upstream change to RocksDB's config cannot silently ship an unresolvable package.
README.md	States that the package resolves its own zlib on every target, so consumers need no preparation.

✅ Verification

Route: a real local vcpkg install on darwin-arm64 plus consumer projects built against the resulting archive. The platform that actually failed cannot be reproduced here.

• Local install reported Restored 0 package(s) and rebuilt both variants from source, so the portfile path really ran; the installed config carries the injection.
• Full archive verification passes with no consumer-side setting: markers 1 vs 0, nm 59 vs 0, probe user_key_comparison_count 40,959 vs 0.
• A consumer declaring cmake_minimum_required(VERSION 3.20) configures and links, resolving ZLIB::ZLIB to the archive's own library.
• Same consumer with CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON, and again with ZLIB already found in config mode: both resolve to the archive's library. Against the unpatched config, PREFER_CONFIG leaves ZLIB::ZLIB undefined, which is the failure this closes.
• An optional find_package(RocksDB CONFIG) stays non-fatal when the archive is incomplete.
• Dependency audit of the published v11.8.1 archives: ZLIB was the only blocker. BZip2 resolves as bz2.lib, and Snappy, lz4 and zstd ship CONFIG files. All six Unix archives carry libz.a.

Not verified here: that MSVC compiles and links the probe against the patched package. build.yml has no pull_request trigger, so a dispatch is the only proof.

❓ Your call: this changes what ships — the archives' RocksDBConfig.cmake gains six lines — which is a wider blast radius than the last three PRs. The one-line probe-side alternative fixes CI with no artifact change, at the cost of leaving the package defect in place and invisible. Say the word and I will swap to it.

Accepted limitations

Matching vcpkg's wrapper means inheriting its edges, each raised in review and left deliberately: a find_library miss degrades to FindZLIB's default search rather than erroring; an absent debug zlib leaves ZLIB_LIBRARY_DEBUG for FindZLIB to resolve; and a consumer-set ZLIB_LIBRARY or a cached value from a previous prefix wins over the pin. Making any of these fatal would break optional find_package(RocksDB), which is why the first attempt at REQUIRED was backed out.

_{🤖 Generated by Claude (Anthropic); posted via @cb1kenobi.}

Related PRs: #29 overlaps (fixed the generator this failure came after; merged), #28 overlaps (merged)
Complexity: medium

_{Review-Coverage: authored=claude; ran=gemini,codex,cursor-composer,cursor-muse; adjudicated=domain; blocked=cursor-grok(failed); declined=cursor-kimi; rounds=3; full=3 @ e51bfff}

_{Review-Attention: study ~20m (critical: portfile.cmake; decisions: patch-generated-config, defer-to-consumer-zlib, static-libs-knob, prove-before-merge; raised: degraded review) @ e51bfff}

[gemini-code-assist]

Code Review

This pull request updates the README and the RocksDB portfile to ensure the package can correctly resolve its static zlib dependency (such as zs.lib on Windows) automatically. In the portfile, it modifies RocksDBConfig.cmake to locate the release and debug zlib libraries relative to the package prefix. The review feedback recommends also finding and caching ZLIB_INCLUDE_DIR using the package's own include directory to prevent FindZLIB from failing to locate zlib.h when a consumer configures their project by setting RocksDB_DIR directly.