Fix build in wasm{32,64}-unknown-unknown with zlib feature

[tbu-]

error[E0432]: unresolved import `libc::c_int`
   --> src/mem.rs:316:13
    |
316 |         use libc::c_int;
    |             ^^^^^^^^^^^ no `c_int` in the root

error[E0432]: unresolved imports `libc::c_int`, `libc::c_uint`, `libc::c_void`, `libc::size_t`
  --> src/ffi/c.rs:10:16
   |
10 | pub use libc::{c_int, c_uint, c_void, size_t};
   |                ^^^^^  ^^^^^^  ^^^^^^  ^^^^^^ no `size_t` in the root
   |                |      |       |
   |                |      |       no `c_void` in the root
   |                |      no `c_uint` in the root
   |                no `c_int` in the root

error[E0432]: unresolved imports `libc::c_char`, `libc::c_int`
   --> src/ffi/c.rs:381:16
    |
381 |     use libc::{c_char, c_int};
    |                ^^^^^^  ^^^^^ no `c_int` in the root
    |                |
    |                no `c_char` in the root

[tbu-]

Test failure seems unrelated?

[alexcrichton]

cc @joshtriplett looks like zlib-ng is still segfaulting?

Otherwise @tbu- can you add CI for this?

[tbu-]

This PR depends on rust-lang/libz-sys#94, which isn't in a libz release yet. Should I add a git dependency on that for the CI job I'm adding?

[alexcrichton]

Hm ok. Personally I'm very wary of C support with the wasm32-unknown-unknown target because there is no corresponding runtime/C ABI to follow. Targets like Emscripten or WASI have well-defined ABIs they're following but the unknown target is sort of a mishmash of whatever works. AFAIK there is no official C or clang toolchain for this target. In that sense landing a PR like this is is baking in assumptions about a particular C compiler that not necessarily everyone is making. I'm not sure how to handle that.

[tbu-]

In that sense landing a PR like this is is baking in assumptions about a particular C compiler that not necessarily everyone is making.

It seems to me that there assumptions are only made by std or the libc crate, not by this pull request. This pull request only replaces types from the libc crate with those from std.

[joshtriplett]

@alexcrichton I can't reproduce that segfault; I tried running the full testsuite for x86_64-unknown-windows-gnu (in wine) and it ran without issues.

[joshtriplett]

@tbu- We don't actually need the size_t type; flate2 doesn't use it for anything, and it doesn't get exported outside the crate. I've pushed a change that fixes this by eliminating usage of the libc crate entirely, rather than still using it conditionally. This also avoids the need for the cfg conditional.

This also fixes #291 .

[tbu-]

Thanks!

[samdenty]

I'm trying to compile an application using flate2 with features = ["zlib-ng-compat",], default-features = false and I'm getting an error:

Install a sysroot for the target platform and configure it via
  PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_PATH, or install a
  cross-compiling wrapper for pkg-config and set it via
  PKG_CONFIG environment variable.
  TARGET = Some("wasm32-unknown-unknown")
  OPT_LEVEL = Some("3")
  HOST = Some("x86_64-apple-darwin")
  CC_wasm32-unknown-unknown = None
  CC_wasm32_unknown_unknown = None
  TARGET_CC = None
  CC = None
  CFLAGS_wasm32-unknown-unknown = None
  CFLAGS_wasm32_unknown_unknown = None
  TARGET_CFLAGS = None
  CFLAGS = None
  CRATE_CC_NO_DEFAULTS = None
  DEBUG = Some("false")
  running: "clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-unknown-unknown" "-I" "src/zlib" "-fvisibility=hidden" "-DZ_SOLO" "-DSTDC" "-D_LARGEFILE64_SOURCE" "-D_POSIX_SOURCE" "-o" "/Users/samdenty/Projects/isomorphic-git/zlib-wasm/target/wasm32-unknown-unknown/release/build/libz-sys-7094e0907550e67a/out/lib/src/zlib/adler32.o" "-c" "src/zlib/adler32.c"
  cargo:warning=error: unable to create target: 'No available targets are compatible with triple "wasm32-unknown-unknown"'
  cargo:warning=1 error generated

Does anyone know how to fix this?