fix vendored libdeflate _rotr* macros vs mingw stdlib.h #1

Merged

jorijnvdgraaf merged 1 commit from fix/mingw-rotr64-stdlib-collision into master

2026-05-27 04:28:37 +02:00

catbot commented

2026-05-27 04:24:18 +02:00

Member

Summary

libdeflate's common/compiler_gcc.h defined _rotl/_rotr/_rotl64/_rotr64 as macros before mingw's <stdlib.h> could declare them as functions.
Any TU including lib_common.h (and thus compiler_gcc.h) and later <stdlib.h> — e.g. lib/utils.c — saw the function declarations textually substituted by the macros, producing a syntax error on x86_64-w64-mingw32.
Fix: pull <stdlib.h> in from compiler_gcc.h on mingw so the declarations are parsed before the macro names shadow them. The later #include <stdlib.h> in utils.c becomes a no-op via the header guard; call sites still expand the macros, so generated code is identical on every other compiler/target.

Why this matters

Crafter.Build's CI Windows cross-compile job (--target=x86_64-w64-mingw32) has been failing for a while at this exact spot — no Windows artifact has been produced since the failure started. Catcrafts/Crafter.Build#6.

Test plan

Crafter.Build CI passes Build Windows x86-64-v2 (mingw) (and v3/v4) once this is merged and a corresponding Crafter.Build change pins the fixed commit.
Linux + wasm jobs unchanged (macros still define identically on those targets).

🤖 Generated with Claude Code

## Summary - libdeflate's `common/compiler_gcc.h` defined `_rotl/_rotr/_rotl64/_rotr64` as macros before mingw's `<stdlib.h>` could declare them as functions. - Any TU including `lib_common.h` (and thus `compiler_gcc.h`) and later `<stdlib.h>` — e.g. `lib/utils.c` — saw the function declarations textually substituted by the macros, producing a syntax error on x86_64-w64-mingw32. - Fix: pull `<stdlib.h>` in from `compiler_gcc.h` on mingw so the declarations are parsed before the macro names shadow them. The later `#include <stdlib.h>` in `utils.c` becomes a no-op via the header guard; call sites still expand the macros, so generated code is identical on every other compiler/target. ## Why this matters Crafter.Build's CI Windows cross-compile job (`--target=x86_64-w64-mingw32`) has been failing for a while at this exact spot — no Windows artifact has been produced since the failure started. Catcrafts/Crafter.Build#6. ## Test plan - [ ] Crafter.Build CI passes `Build Windows x86-64-v2 (mingw)` (and v3/v4) once this is merged and a corresponding Crafter.Build change pins the fixed commit. - [ ] Linux + wasm jobs unchanged (macros still define identically on those targets). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

catbot added 1 commit

2026-05-27 04:24:18 +02:00

fix vendored libdeflate _rotr* macros colliding with mingw stdlib.h 021ced683d

compiler_gcc.h defined _rotl/_rotr/_rotl64/_rotr64 as macros before
mingw's <stdlib.h> got a chance to declare them as functions. Any
translation unit that did `#include "lib_common.h"` (which transitively
pulls in compiler_gcc.h) and later included <stdlib.h> — utils.c does
exactly this — would have the mingw function declarations textually
substituted by the macros, producing a syntax error.

Force <stdlib.h> in from compiler_gcc.h on mingw so the function
declarations are parsed before the macro names get shadowed. The
later #include in utils.c becomes a no-op via the header guard, and
call sites still resolve to the macros below (so the generated code
is unchanged on every other compiler/target).

This unblocks the Crafter.Build CI's x86_64-w64-mingw32 cross-compile,
which has been failing for a while when building Crafter.Asset →
gdeflate → libdeflate as a dep.