-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
libz-sys
1.1.7 fails to build with current crane
#613
Comments
Hi @Benjamin-L thanks for the report! It looks like libz-sys 1.1.17 has been yanked: rust-lang/libz-sys#194 Even if I force Cargo to build a lock file with the yanked version, adding {
inputs = {
nixpkgs.follows = "crane/nixpkgs";
flake-utils.url = "github:numtide/flake-utils";
crane.url = "github:ipetkov/crane";
};
outputs = inputs@{ self, crane, flake-utils, ... }: flake-utils.lib.eachDefaultSystem (system: {
packages.default = crane.lib.${system}.buildDepsOnly {
src = ./.;
buildInputs = with inputs.nixpkgs.legacyPackages.${system}; [
libz
];
};
});
} I'm going to resolve this as I don't think there is anything we can do here (plus there is a fix in the works for libz-sys here: rust-lang/libz-sys#195) but feel free to reopen if I've gotten something wrong! |
Describe the bug
Attempting to build a package that depends on
libz-sys
1.1.7 with crane results in the following error:The most recent version of
libz-sys
introduced some lines to the build script that dofs::copy($path_in_src, $path_in_out_dir)
. Looking at the build log, it appears that the build script is being run twice: first as part ofcargo check
and then as part ofcargo build
. This looks very similar to the situation described here, where the firstfs::copy
is preserving the-r
permissions on the file in the src directory, preventing the secondfs::copy
from overwriting the output file.Reproduction
Cargo.toml
:flake.nix
:nix build .
Full log with CARGO_TERM_VERBOSE=true:
The text was updated successfully, but these errors were encountered: