The android NDK (android-ndk-r21e) does not have crc32_z, adler32_z, nor z_size_t in its zlib.h header file. However, it does have the crc32_z and adler32_z symbols in the libz.a static library!
mkmf performs two tests for have_func:
It sees if a program that includes the header and takes the address of the symbol can compile
It sees if a program that defines the symbol as extern void sym_name() and calls it can be linked
If either test works, it considers the function present. The android-ndk-r21e is passing the second test but not the first for crc32_z/adler32_z. So, we define HAVE_ZLIB_SIZE_T_FUNCS, but then can't actually compile the extension (since the prototypes aren't in the header file).
We can keep this working how it was working before by also checking for have_type("z_size_t", "zlib.h"). The have_type check only looks in the header file for the type; if a program including the header file and using the type can't compile, the type is considered absent regardless of what might be in libz.a.
The android NDK (android-ndk-r21e) does not have crc32_z, adler32_z, nor z_size_t in its zlib.h header file. However, it does have the crc32_z and adler32_z symbols in the libz.a static library!
mkmf performs two tests for have_func:
extern void sym_name()and calls it can be linkedIf either test works, it considers the function present. The android-ndk-r21e is passing the second test but not the first for crc32_z/adler32_z. So, we define HAVE_ZLIB_SIZE_T_FUNCS, but then can't actually compile the extension (since the prototypes aren't in the header file).
We can keep this working how it was working before by also checking for
have_type("z_size_t", "zlib.h"). The have_type check only looks in the header file for the type; if a program including the header file and using the type can't compile, the type is considered absent regardless of what might be in libz.a.This fixes the build breakage introduced in https://github.com/ruby/zlib/pull/68