Description
When libz-sys
fails to find zlib
, it falls back to building it from source.
However, when curl-rust
vendors libcurl
(when it falls back), it transitively depends on either zlib
being present in system include paths or libz-sys
vendoring it into the same paths:
Lines 57 to 59 in ff6ad21
libz-sys
recently attempted to use pkg-config
on Windows, which broke curl-sys
using an MSVC toolchain (from inside an MSYS2 environment, presumably without vcpkg
), because it would no longer need to build zlib
from source: rust-lang/libz-sys#143
However, because curl-sys
does not support pkg-config
(#486), on Windows:
- on an MSVC host and MSVC target, it will attempt to find
libcurl
withvcpkg
(Allow using vcpkg on any Windows target, and use find_package #509 would slightly improve this) - otherwise, it just builds
libcurl
from source
When building from source, curl-sys
generates a pkg-config
file, but doesn't add any linkage or include path information for zlib
:
Lines 98 to 100 in ff6ad21
...and enables zlib
support:
Line 127 in ff6ad21
...it might get something from vcpkg
if built on an MSVC host (because build.rs
cfg directives are based on the host, not the target):
Lines 296 to 299 in ff6ad21
...but otherwise this means zlib.h
needs to be in $OUT_DIR/include
(which it gets from libz-sys
' vendoring) or in the system include paths (which it gets on most non-Windows platforms).
When vendoring libcurl
, curl-sys
should find zlib
properly (ideally, the same way as libz-sys
does).
It would be better if you needed to explicitly enable vendoring in this library, because while "silent fallback" can be helpful, it leads to surprising behaviour like this, and makes it more difficult to audit your dependencies.