v1.1.26 missing src/zlib/ sources in published crate (Windows build broken)

[jdx]

Summary

libz-sys 1.1.26 published to crates.io is missing the src/zlib/ directory contents. This breaks all builds that compile zlib from source (notably Windows).

Details

The crate tarball only contains src/lib.rs and src/smoke.c — none of the vendored zlib C sources:

$ tar tzf libz-sys-1.1.26.crate | grep "src/"
libz-sys-1.1.26/src/lib.rs
libz-sys-1.1.26/src/smoke.c

For comparison, 1.1.25 correctly includes src/zlib/*.c and src/zlib/*.h.

This causes Windows builds to fail with:

error: failed to run custom build command for `libz-sys v1.1.26`
c1: fatal error C1083: Cannot open source file: 'src/zlib/adler32.c': No such file or directory

The src/zlib directory is a git submodule in the repo. It appears cargo publish did not vendor the submodule contents into the crate tarball.

This is the same class of bug that caused v1.0.26 to be yanked.

Suggested fix

Yank 1.1.26 and re-publish with the submodule contents properly included (e.g. by running cargo publish with --allow-dirty from a checkout with submodules initialized, or by using a build script that doesn't rely on submodule vendoring).

This issue was generated by Claude Code.

[Byron]

Can you try again with with the most recent release of libz-ng-sys?

[mdecimus]

Hi @Byron, it hasn't been fixed yet, the issue is with libz-sys which remains on 1.1.26 on crates.io:

% cargo update
    Updating crates.io index
     Locking 6 packages to latest compatible versions
    Updating libz-sys v1.1.25 -> v1.1.26
note: pass `--verbose` to see 17 unchanged dependencies behind latest
% LOG=debug RUST_BACKTRACE=1 STORE="RocksDb" cargo test report_scheduler -- --nocapture
  Downloaded 5 crates (335.5KiB) in 0.39s
   Compiling libz-sys v1.1.26
warning: libz-sys@1.1.26: clang: error: no such file or directory: 'src/zlib/adler32.c'
warning: libz-sys@1.1.26: clang: error: no input files
warning: libz-sys@1.1.26: ToolExecError: command did not execute successfully (status code exit status: 1): env -u IPHONEOS_DEPLOYMENT_TARGET LC_ALL="C" "cc" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-gdwarf-2" "-fno-omit-frame-pointer" "--target=arm64-apple-macosx" "-mmacosx-version-min=26.2" "-I" "src/zlib" "-w" "-fvisibility=hidden" "-DZ_SOLO" "-DNULL=0" "-DSTDC" "-D_LARGEFILE64_SOURCE" "-o" "/Users/me/code/stalwart/target/debug/build/libz-sys-016aedf15a077217/out/lib/f0389296f42960e9-adler32.o" "-c" "src/zlib/adler32.c"cargo:rerun-if-env-changed=CC_aarch64-apple-darwin
warning: libz-sys@1.1.26: clang: error: no such file or directory: 'src/zlib/compress.c'
warning: libz-sys@1.1.26: clang: error: no input files

[Its-Just-Nans]

Hi

I have a similar error I think

On the CI https://github.com/zip-rs/zip2/actions/runs/23984510848/job/69954113586?pr=763

  --- stderr
  running: cd "/home/runner/work/zip2/zip2/semver-checks/target/debug/build/libz-sys-003ae20244733462/out/build" && CMAKE_PREFIX_PATH="" LC_ALL="C" "cmake" "/home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/libz-sys-1.1.26/src/zlib-ng" "-B" "/home/runner/work/zip2/zip2/semver-checks/target/debug/build/libz-sys-003ae20244733462/out/build" "-DBUILD_SHARED_LIBS=OFF" "-DZLIB_COMPAT=ON" "-DZLIB_ENABLE_TESTS=OFF" "-DWITH_GZFILEOP=ON" "-DCMAKE_INSTALL_LIBDIR=lib" "-DCMAKE_INSTALL_PREFIX=/home/runner/work/zip2/zip2/semver-checks/target/debug/build/libz-sys-003ae20244733462/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64 -w" "-DCMAKE_C_COMPILER=/usr/bin/cc" "-DCMAKE_CXX_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64 -w" "-DCMAKE_CXX_COMPILER=/usr/bin/c++" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64 -w" "-DCMAKE_ASM_COMPILER=/usr/bin/cc" "-DCMAKE_BUILD_TYPE=Debug"
  CMake Error: The source directory "/home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/libz-sys-1.1.26/src/zlib-ng" does not exist.
  Specify --help for usage, or press the help button on the CMake GUI.

  thread 'main' (3110) panicked at /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cmake-0.1.58/src/lib.rs:1132:5:

  command did not execute successfully, got: exit status: 1

  build script failed, must exit now
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[ggarra13]

Confirmed the issue myself on both Windows amd64 and Windows arm64 Github builds.

[Byron]

So it seems both versions were broken because of a lack of submodules. That makes sense actually, even though it's completely impossible for me to fathom how cargo publish can succeed as it will try to build the crate it's about to publish.

@Its-Just-Nans It seems the failure still stems from libz-ng-sys v1.1.26, while 1.1.27 is the one that should work.

I have re-released libz-sys as 1.1.27 as well, so now it should work.

[Its-Just-Nans]

I have re-released libz-sys as 1.1.27 as well, so now it should work.

CI is working again https://github.com/zip-rs/zip2/actions/runs/23984510848/job/69967785418?pr=763 so it seems to work

[Byron]

Great! My greatest apologies for this!

It turns out I was relying on cargo publish to fail with default features, even though these resort to using system libraries instead.

---

cargo publish still succeeded because its verification step only checks that the packaged crate can build in the selected/default configuration, not that every feature path is valid. Cargo documents that cargo pa
ckage creates the tarball, then extracts it and “build[s] it to verify it can build” (docs (https://doc.rust-lang.org/cargo/commands/cargo-package.html)), and feature selection defaults to the package’s default f
eatures (docs (https://doc.rust-lang.org/cargo/commands/cargo-package.html#feature-selection)). In this crate, default features are libc + stock-zlib (Cargo.toml:64), and build.rs prefers a system zlib before com
piling bundled source (build.rs:16). So on a machine with system zlib, the packaged crate builds fine even though the bundled source trees are absent. I reproduced that too: the published 1.1.26 tarball builds by
default, but fails with --features static and with --no-default-features --features zlib-ng.

---

I will try to create a release tool that will prevent this, along with a maintenance guide, as clearly the system right now relies on 'expert' mode where git submodules are expected to be there, and I failed to be the expert, years later, and all it took is a second machine that wasn't initialized correctly.