diff --git a/.github/workflows/mswin-build.yml b/.github/workflows/mswin-build.yml
index 94cc4dd..c49b770 100644
--- a/.github/workflows/mswin-build.yml
+++ b/.github/workflows/mswin-build.yml
@@ -91,6 +91,22 @@ jobs:
           echo "CONFIGURE_ARGS=$args" >> "$GITHUB_ENV"
         shell: bash
 
+      - name: Backport -we4013 to the mswin warnflags
+        # ruby/ruby 091c7d4a54 made C4013 (implicit function declaration)
+        # an error on mswin.  Without it, mkmf's have_func probe for a
+        # compiler builtin such as __builtin_clzll compiles on a bare
+        # implicit declaration and reports a false positive, which then
+        # fails to link.  json's parser hits exactly this on Ruby 3.3.
+        # The fix ships in 3.4 and later, so patch only the older trees
+        # that still lack it, mirroring the vcpkg.json override above.
+        run: |
+          set -ex
+          if ! grep -q 'we4013' src/win32/Makefile.sub; then
+            sed -i 's/-we4028 -we4142 -we4047$/-we4028 -we4142 -we4047 -we4013/' src/win32/Makefile.sub
+            grep -q 'we4013' src/win32/Makefile.sub
+          fi
+        shell: bash
+
       - name: Install tools with scoop
         run: |
           if ((vcpkg.exe help install) -match "manifest") { exit }
diff --git a/README.md b/README.md
index 1731d6d..242e32a 100644
--- a/README.md
+++ b/README.md
@@ -48,7 +48,7 @@ Package names:
 - Release: `ruby-<version>-x64-mswin64_140` (e.g. `ruby-3.4.5-x64-mswin64_140`)
 - Snapshot: `ruby-<version>dev-<yyyymmdd>-<commit>-x64-mswin64_140`, so that a dev build can never collide with a release package name
 
-Releases are built from the official release tarball on cache.ruby-lang.org, verified against `pub/ruby/index.txt`. Snapshots are built from a fresh clone of the master branch. Ruby 3.3 has no in-tree `vcpkg.json`, so the builder supplies `tool/mswin/vcpkg-ruby_3_3.json` instead. Packaging is done by `tool/binary-package.rb` from ruby/ruby, downloaded at the commit pinned in `BINARY_PACKAGE_REF` in `mswin-build.yml`. Bumping that SHA is the whole sync with upstream. The script is applied from the outside to the staged install rather than via the in-tree `nmake binary-package` target, so that already-released tarballs (which predate the script) can be packaged and the snapshot naming stays under this repository's control. Before archiving, the script scrubs build-machine paths (such as the `--with-opt-dir` vcpkg path) from the staged `rbconfig.rb` `configure_args`, since mkmf feeds those to every extension build and a leaked absolute path would break gem compilation on the destination machine. Only the staged copy is touched, never the build machine's own installation.
+Releases are built from the official release tarball on cache.ruby-lang.org, verified against `pub/ruby/index.txt`. Snapshots are built from a fresh clone of the master branch. Ruby 3.3 has no in-tree `vcpkg.json`, so the builder supplies `tool/mswin/vcpkg-ruby_3_3.json` instead. Ruby 3.3 also predates ruby/ruby `091c7d4a54`, which makes the mswin C4013 warning an error, so the builder appends `-we4013` to its warnflags. Without it `mkmf`'s `have_func` probe for a compiler builtin like `__builtin_clzll` compiles a bare implicit declaration, reports a false positive, and then fails to link, which breaks `gem install json` on the packaged 3.3. Both overrides target only the older trees that need them and no-op on 3.4 and later. Packaging is done by `tool/binary-package.rb` from ruby/ruby, downloaded at the commit pinned in `BINARY_PACKAGE_REF` in `mswin-build.yml`. Bumping that SHA is the whole sync with upstream. The script is applied from the outside to the staged install rather than via the in-tree `nmake binary-package` target, so that already-released tarballs (which predate the script) can be packaged and the snapshot naming stays under this repository's control. Before archiving, the script scrubs build-machine paths (such as the `--with-opt-dir` vcpkg path) from the staged `rbconfig.rb` `configure_args`, since mkmf feeds those to every extension build and a leaked absolute path would break gem compilation on the destination machine. Only the staged copy is touched, never the build machine's own installation.
 
 Every built zip is smoke-tested in the workflow. The zip is extracted, the root name, layout and checksum are checked, the packaged `ruby.exe` is run with PATH restricted to System32 while loading openssl, fiddle, psych and zlib, and its `configure_args` is asserted to carry no absolute path. A native gem (`json`) is then compiled against the package under the VS toolchain to confirm the extension build pulls in no vcpkg path. The zip and its checksum are uploaded as an Actions artifact. Publishing to cache.ruby-lang.org is not wired up yet.