zlib-rs and cloudflare_zlib features conflict

[fintelia]

If you try to enable both the zlib-rs and cloudflare_zlib features:

[dependencies]
flate2 = { version = "1.0.35", features = ["zlib-rs", "cloudflare_zlib"] }

Then there are some compile errors:

error[E0252]: the name `libz` is defined multiple times
   --> /home/jonathan/.cargo/registry/src/index.crates.io-6f17d22bba15001f/flate2-1.0.35/src/ffi/c.rs:412:9
    |
409 |     use libz_rs_sys as libz;
    |         ------------------- previous import of the module `libz` here
...
412 |     use cloudflare_zlib_sys as libz;
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^ `libz` reimported here
    |
    = note: `libz` must be defined only once in the type namespace of this module
help: you can use `as` to change the binding name of the import
    |
412 |     use cloudflare_zlib_sys as other_libz;
    |                             ~~~~~~~~~~~~~
...

I believe this is can be fixed by establishing precedence between the two flags here:

flate2-rs/src/ffi/c.rs

Lines 408 to 412 in 14aec22

	#[cfg(all(not(feature = "zlib-ng"), feature = "zlib-rs"))]
	use libz_rs_sys as libz;
	#[cfg(all(not(feature = "zlib-ng"), feature = "cloudflare_zlib"))]
	use cloudflare_zlib_sys as libz;

[Byron]

Thanks for reporting and for the initial analysis!

A PR to setup such precedence would definitely be welcome

[oyvindln]

Is there still a need to keep the cloudflare feature at all or could we just make it an alias to one of the zlib_ng variants for backwards compatability since zlib_ng incorporates the improvements from that fork anyhow? (or at least consider that in the next version that allows breakage)

[Byron]

Thanks for pointing that out!
That would definitely something for the next minor release, just to be sure. Meanwhile, one could probably make it work like suggested here.

[oyvindln]

strictly speaking the zlib-ng readme is a bit unclear whether it's some or all but since it's performance improvements and not any extra functionality it might not be worth supporting both if zlib-ng (or the rust port) performs as good or better anyhow and cloudflare-zlib has more limited hardware support and sees much less updates. (One thing I don't know is whether it also makes the tradeoff of limiting to matches to a min length of 4 and thus achieves slightly less efficient compression in some cases compared to vanilla zlib like zlib-ng does so if somehow anyone relies on that that would be a counterpoint.)

[kornelski]

This isn't a fundamental conflict between the crates, only a #[cfg()] in flate2 is missing a condition.

cloudflare-zlib is a drop-in replacement for the original C zlib (it has the same C API/ABI). As long as you support the original zlib, supporting cloudflare-zlib should be easy.

cloudflare-zlib is similar to zlib-ng, but it's easier to build (and cross-compile) in Rust, because it uses the cc crate instead of cmake.