Skip to content
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

Installation on windows is failing #595

Closed
AntoniosBarotsis opened this issue Dec 27, 2022 · 1 comment · Fixed by #596
Closed

Installation on windows is failing #595

AntoniosBarotsis opened this issue Dec 27, 2022 · 1 comment · Fixed by #596

Comments

@AntoniosBarotsis
Copy link
Contributor

AntoniosBarotsis commented Dec 27, 2022

$ cargo install hyperfine

error[E0432]: unresolved import `winapi::um::handleapi`
 --> C:\Users\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\hyperfine-1.15.0\src\timer\windows_timer.rs:9:9
  |
9 |         handleapi::CloseHandle,
  |         ^^^^^^^^^ could not find `handleapi` in `um`

For more information about this error, try `rustc --explain E0432`.

I got this error on a workflow run today even though everything was working perfectly fine a few days ago when it last ran.

After some digging around, the winapi crate turned out to have a flag for handleapi, enabling that in the Cargo.toml file fixes the issue.

I'm not experienced enough to really understand how this broke now considering how both this and the winapi crates have not been updated that recently but it was suggested to me in the Rust Discord that some lockfile somewhere was perhaps requiring an older version of one of these crates which did not need the explicit feature requirement.

This was tested locally by cloning the repo and installing it with cargo install --path ./hyperfine which only worked after the change I made in the pull request.

AntoniosBarotsis added a commit to AntoniosBarotsis/hyperfine that referenced this issue Dec 27, 2022
sharkdp pushed a commit that referenced this issue Jan 8, 2023
@sharkdp
Copy link
Owner

sharkdp commented Jan 8, 2023

I'm not experienced enough to really understand how this broke now considering how both this and the winapi crates have not been updated that recently

I think it comes down to whether you run cargo install --locked or just cargo install. With the --locked option, you build exactly the same software as specified in the lock file. Without that option, cargo does semver-compatible updates of dependencies, and there might have been some breakage somewhere.

This bug would have shown up in CI eventually, so thank you for reporting it and fixing it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants