Don't depend on libc crate when only compiled with rust_backend

[jrmuizel]

It shouldn't be need in that case.

[Craig-Macomber]

It looks like libc is needed (in the top level Cargo.toml) only if cfg(any(feature = "miniz-sys", feature = "any_zlib")).

My understanding of the Cargo.toml format is we don't have a way to deal with the "miniz-sys" case without making a breaking change (or some other significant refactoring, like adding an indirection crate so we avoid having a direct dep named "miniz-sys"), since users of this crate using that feature, but not the default feature, have no way to get opted into an getting libc, since we can't have a feature name that overlaps an optional dependency, and can't make the optional dependency cause another dependency.

Here is a fix, though as noted above, this is a breaking change for users of the miniz-sys feature: https://github.com/Craig-Macomber/flate2-rs/tree/un-libc

[oyvindln]

If the only parts of libc used are the C data types, it's possible you could do a temporary workaround using a cut-down version of libc or similar (not sure if there are any existing crates for this) with only that included. There is something similar in the C API part of miniz_oxide though it's not really used for much atm, though one would need a much more extensive one to account for different platforms probably. Maybe a case for a new libc_types crate or similar.

libc also has a std feature which can be turned off which may or may not be helpful here.

[LingMan]

The libc dependency was recently eliminated entirely (https://github.com/rust-lang/flate2-rs/commit/a4628b7955a5564e1fb8ce37ed18affb09f42b18), so I guess this issue could be closed?

[JohnTitor]

Closing as fixed