fix(build): use system zlib instead of missing vendored sources

[poshboytl]

Summary

• Add LIBZ_SYS_STATIC=0 to .cargo/config.toml to link system zlib instead of vendored sources
• The dependency chain rocksdb -> librocksdb-sys (static) -> libz-sys (static) forces libz-sys 1.1.26 to compile vendored zlib from src/zlib/, but the crate does not ship those sources, causing build failure
• This affects anyone cloning the repo, not just a local environment issue

[janx]

@claude review

[claude]

Claude finished @janx's task in 1m 32s —— View job

---

PR Review

• Read changed files
• Analyze the fix
• Check related files (CI, Cargo.toml, etc.)
• Post review feedback

---

Summary

The fix is correct and minimal. The dependency chain rocksdb = "0.24" → librocksdb-sys (compiled statically) → libz-sys forces vendored zlib compilation, but libz-sys 1.1.x doesn't bundle the src/zlib/ sources in its published crate — it expects them to be fetched via a build script or provided by the system. Setting LIBZ_SYS_STATIC=0 is the idiomatic way to resolve this.

Verdict: Looks good with one CI concern noted below.

---

.cargo/config.toml — The fix itself

[env]
RUST_TEST_THREADS = "4"
LIBZ_SYS_STATIC = "0"   # ← added

Correct approach. libz-sys checks for LIBZ_SYS_STATIC=1 to activate vendored compilation; setting it to "0" (or any non-"1" value) causes it to probe for a system-installed libz instead. This is the standard, documented way to control libz-sys linking behavior.

[env] does not force-override shell env. Per Cargo's config spec, entries in [env] are only applied if the variable is not already set in the environment (unless force = true is added). So if someone runs with LIBZ_SYS_STATIC=1 exported in their shell, the config entry won't override it and they'll hit the original build failure. This is unlikely in practice, but worth being aware of. If you want to guarantee this setting regardless of the caller's environment, use:

LIBZ_SYS_STATIC = { value = "0", force = true }

That said, forcing env vars in config.toml can be surprising, so leaving it as-is is reasonable — just document it.

---

CI gap

.github/workflows/ci.yml has no explicit apt-get install zlib1g-dev step in the Rust job. Ubuntu ubuntu-latest runners ship with zlib1g (the shared lib) and zlib1g-dev (the headers) pre-installed, so the CI will work today. But this is now an implicit system dependency — if the runner image ever changes or the project is built in a minimal container, the build will fail with a different error (missing -lz or missing zlib.h).

Suggestion: add this to the Rust CI job for explicitness:

- name: Install system dependencies
  run: sudo apt-get install -y zlib1g-dev

This makes the dependency visible and prevents silent breakage in containerized environments (Docker, devcontainers, etc.).

---

Alternatives considered

A [target.cfg(...).rustflags] entry or a workspace Cargo.toml patch would be heavier and less idiomatic for this use case. The env var approach here is the right level of fix.

---