Check for z_size_t along with {crc,adler}32_z in extconf.rb #69
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
ioquatix
approved these changes
Oct 26, 2023
matzbot
pushed a commit
to ruby/ruby
that referenced
this pull request
Oct 26, 2023
extconf.rb (ruby/zlib#69) 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. ruby/zlib@3b9fe962d8
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 #68