Skip to content

[Android] Fix zlib fdopen macro breaking macOS builds#39

Closed
azad-uber-2 wants to merge 1 commit into
uber-common:uber/android/8.1.1from
azad-uber-2:azad/fix-zlib-fdopen-macos
Closed

[Android] Fix zlib fdopen macro breaking macOS builds#39
azad-uber-2 wants to merge 1 commit into
uber-common:uber/android/8.1.1from
azad-uber-2:azad/fix-zlib-fdopen-macos

Conversation

@azad-uber-2

Copy link
Copy Markdown

Summary

On modern macOS, TARGET_OS_MAC is always 1 (set by system headers), causing #define fdopen(fd,mode) NULL to fire in third_party/zlib/zutil.h. This macro replaces the fdopen token everywhere, which breaks when the macOS SDK's _stdio.h declares FILE *fdopen(int, const char *) — the compiler sees FILE *NULL(int, const char *) and errors out.

The removed #else branch was written for classic Mac OS (pre-OS X) using non-Metrowerks compilers that no longer exist. Modern macOS provides fdopen via the system and needs no macro.

Test plan

  • Bazel binary builds successfully on macOS after this fix (previously failed with fdopen redefinition error)

🤖 Generated with Claude Code

Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com

On modern macOS, TARGET_OS_MAC is always 1 (set by system headers),
causing `#define fdopen(fd,mode) NULL` to fire. This macro replaces
the fdopen token everywhere, which breaks when the macOS SDK's
_stdio.h declares `FILE *fdopen(int, const char *)` — the compiler
sees `FILE *NULL(int, const char *)` and errors out.

The #else branch was written for classic Mac OS (pre-OS X) using
non-Metrowerks compilers that no longer exist. Modern macOS provides
fdopen via the system and needs no macro.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant