Skip to content

compile error #205

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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/github.heygears.com-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/github.heygears.com-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.

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

Successfully merging a pull request may close this issue.

4 participants