Open EliahKagan opened 1 week ago
Thanks so much for the detailed report, and for trying to get to the bottom of this!
It looks like this is a known zlib-ng
incompatibility, and 32bit support for Win MSVC might not be their priority or is entirely unsupported, hence CMake ends up failing.
There is two points I can share:
zlib-ng-no-cmake-experimental-community-maintained
feature toggle which avoids using CMake. If this would work for gitoxide
, maybe it should switch to it.flate2
crate which gitoxide
is using also has a zlib-ng-rs
feature, maybe that will build on 32 bit platforms. If so, maybe it could be used on certain targets by default.
Building fails with an error getting the
VCTargetsPath
On a 32-bit x86 Windows 10 system (build 19041.vb_release.191206-1406), where Rust is using the Visual C++ Build tools (
rustup
toolchainstable-i686-pc-windows-msvc
), attempting commands such ascargo build
orcargo test
in any projects that uselibz-ng-sys
fails with the error:The
amd64
part looks wrong, since this is not cross-compilation and this is a 32-bit system. That directory does exist, but it seems odd that it would be used here and perhaps that is relevant.Discovery and relationship to gitoxide
I originally had this problem when attempting to build or install
gitoxide
. It happens both withcargo install gitoxide
and with commands likecargo build
invoked in the clonedgitoxide
repository directory. The problem appears specific tolibz-ng-sys
, though I am unsure if the problem is in this Rust create or in the underlying native library.cargo install gitoxide --no-default-features --features max-pure
allows the build to succeed by not depending onlibz-ng-sys
.cargo build --release --no-default-features --features max-control,gix-features/zlib-stock,gitoxide-core-blocking-client,http-client-curl
, which is documented to have the same effect as the defaultmax
feature except to use "the stockzlib
library instead ofzlib-ng
," likewise succeeds.Why this is not specific to gitoxide
I don't think the bug--assuming this is a bug, rather than a configuration problem that I may not properly understand--is in
gitoxide
, since this always happens withlibz-ng-sys
. Here's a simpler example, in a project that doesn't have anything else going on besides itslibz-ng-sys
dependency:Why this is probably not related to the
cmake
crate codeI don't believe the problem is in
cmake-rs
. Setting environment variables to get a readable backtrace and repeating the build gives:The reference to
cmake-rs
code, other than itsfail
function, is to this invocation of thecmake
command:So that's just the
cmake
external command failing.The system has a working
cmake
commandI don't think the problem is with
cmake
itself. It is installed and otherwise working:Toolchain and environment variations tested
Because Visual Studio 2022 does not support 32-bit systems, I obtained the needed MSVC toolchain by installing the Visual Studio C++ build tools, which is also an approach listed in the Getting started instructions for Rust on Windows. Specifically, I installed the Visual Studio Build Tools 2022, version 17.10.3, selecting "Desktop development with C++."
Originally I went with the default selections, which included "Windows 11 SDK (10.0.22621.0)" and no other Windows SDKs. The build attempted to use this SDK. But it is a Windows 11 SDK, on a Windows 10 system. Just in case that was the problem, I uninstalled all Rust tools with
rustup
, verified that my.cargo
directory was deleted, uninstalled that Windows 11 SDK, and installed all four of the Windows 10 SDKs instead (10.0.20348.0, 10.0.19041.0, and 10.0.18362.0) in the Visual Studio Installer, and then bootstrappedrustup
again and started over. The above output is all from after doing that.Although I would not expect
cargo
commands to require binaries provided by those build tools to be in thePATH
(and other builds, including e.g. those that usecurl-sys
, are working), I have repeated the above from the Developer PowerShell for VS 2022, which has them. This gave the same result. I did this both times, with the default build tools installation that had a Windows 11 SDK, and after modifying that installation to have no Windows 11 SDKs and all available Windows 10 SDKs.