Let create_header pick up OS_CODE - #147
Merged
Merged
Conversation
mkmf's create_header ignores $defs entries that do not start with -D, so the leading space dropped OS_CODE from extconf.h. The in-tree build of ruby/ruby then fell back to OS_UNIX in zlib.c, and Zlib::OS_CODE was 3 on Windows. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
test_os_code only compared the written os_code with Zlib::OS_CODE itself, so it could not catch OS_CODE falling back to OS_UNIX. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Zlib::OS_CODEisOS_UNIX(3) in the bundled zlib of ruby/ruby on Windows, even thoughextconf.rbdetects Win32. TheOS_CODEentry in$defsstarts with a space, and mkmf'screate_headeronly reads entries that start with-D, soextconf.hlacks it andzlib.cfalls back toOS_UNIX. The standalone gem build is not affected because it passes$defson the command line.I confirmed on x64-mswin64_140 that
extconf.hnow has#define OS_CODE OS_WIN32andZlib::OS_CODEis 11. On Linux the value stays 3.test_os_codenow checks the value on Windows, but it can fail only in the ruby/ruby build because the CI here builds the gem standalone.As a result, gzip files that
GzipWriterwrites by default on Windows get OS byte 11 instead of 3. This includes.gemfiles built withgem build.Generated with Claude Code