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

compile error #205

Closed
sallyyu0 opened this issue Aug 14, 2019 · 9 comments · Fixed by #206
Closed

compile error #205

sallyyu0 opened this issue Aug 14, 2019 · 9 comments · Fixed by #206

Comments

@sallyyu0
Copy link

Suddenly got this error, seems related to the new release. Note that I'm not using this crate directly. Any ideas?

Compiling flate2 v1.0.10
error[E0658]: use of unstable library feature 'rustc_private': this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via Cargo.toml instead?
--> /home/rust/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/flate2-1.0.10/src/lib.rs:89:1
|
89 | extern crate libc;
| ^^^^^^^^^^^^^^^^^^
|
= note: for more information, see rust-lang/rust#27812

error[E0658]: use of unstable library feature 'rustc_private': this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via Cargo.toml instead?
--> /home/rust/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/flate2-1.0.10/src/ffi.rs:52:20
|
52 | pub use libc::{c_int, c_uint, c_void, size_t};
| ^^^^^
|
= note: for more information, see rust-lang/rust#27812

@oyvindln
Copy link
Contributor

Right, this seems to have been a result of me moving libc to optional features in my miniz_oxide commit (as it wasn't needed at all any longer when using the rust backend.)

If you compile the crate with --no-default-features and don't specify any features, it breaks as libc will not have been specified in Cargo.toml. I presume it doesn't break on miniz_sys in the same way since that resides as a subfolder. What crate is it that's using flate2-rs in this way?

@alexcrichton
Copy link
Member

Hm I don't think this crate has ever compiled successfully with --no-default-features, @sallyyu0 can you indicate how you're depending on this crate?

@oyvindln
Copy link
Contributor

oyvindln commented Aug 14, 2019

It compiles with --no-default-features when up to 0.2.11 it seems. After that it will break on extern crate miniz_sys (0.2.12 is when the zlib backend was added.)

That seems to be a bit old for a current crate to depend on.

@dmit
Copy link

dmit commented Aug 14, 2019

In my project it's actix-http 0.2.9 (via latest actix-web) that depends on flate2 with default-features = false:
https://github.com/actix/actix-web/blob/979c4d44f4626e4346714753106d2e94c9b845d1/actix-http/Cargo.toml#L93

If I put flate2 = "1.0.10" in my Cargo.toml without any feature flags, then the libc crate is added as a dependency of flate2 in Cargo.lock and the project builds fine.

@oyvindln
Copy link
Contributor

I presume the actix author's intention is to allow chosing between what flate2 backend to use with two different features in the actix-http crate. The the non-rust one is specified as using the miniz-sys feature (which does not exist).

Doing cargo test --no-default-features --features miniz-sys works fine on 1.0.9, but not on 1.0.10.
cargo test --no-default-features --features "miniz-sys libc" does work on 1.0.10 on the other hand.

Is this how cargo is supposed to work?

@alexcrichton
Copy link
Member

Yes Cargo is working as intended here, and it's a bug in this crate basically that there wasn't a dedicated feature for turning on the miniz backend. It was implicitly left as miniz-sys, and looks like we need to keep that working. I've posted #206 to fix things.

@oyvindln
Copy link
Contributor

I suppose a change to add feature and make it optional would need a major version bump then. Wasn't aware of the possibility of using a dependency as a feature in this way.

@sallyyu0
Copy link
Author

Thanks all for the input. Here is what I did to pass the build.

  1. added flate2 = "=1.0.10" in Cargo.toml (I did not have this and from the logs of last build, it was 1.0.9), this fixed cargo build but still get a failure in cargo test

  2. updated rust compiler from 1.33 to 1.34, passed cargo test.

@alexcrichton
Copy link
Member

Heh no worries @oyvindln, I also didn't realize that your change was technically a breaking change! We can fix this via other methods with renaming dependencies maybe, but it's basically easiest for now to just keep things working as they were before.

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.

4 participants