Windows 8.3/8.4 SDKs: php8embed.lib missing the ephpm OPcache SAPI-allowlist patch - OPcache never activates in serve mode

[luthermonson]

Found during ephpm#350 (shaped JIT default) verification.

Symptom: on Windows builds against the 8.3.31 SDK, opcache_get_status() returns false in serve mode - OPcache never activates, so opcache and the JIT are silently inert. CLI mode works (SAPI name is "cli" there). PHP 8.5 SDKs are unaffected.

Evidence: binary grep of 8.3.31-windows-x86_64\lib\php8embed.lib: the OPcache supported_sapis allowlist contains frankenphp and litespeed but not ephpm - the SDK's allowlist patch (which the Linux/macOS 8.3/8.4 builds carry, and which 8.5 no longer needs since upstream removed the allowlist) was evidently not applied to the Windows lane's build for <= 8.4.

Impact: every Windows ephpm serve deployment on PHP 8.3/8.4 runs with zero opcode caching - a large silent performance loss, and ephpm#350's JIT-by-default is a no-op there. 8.5 unaffected (no allowlist upstream).

Fix: apply the same allowlist patch in the Windows build path for 8.3/8.4, or verify why it was skipped. The artifact-level check is cheap: strings php8embed.lib | grep ephpm alongside the existing sapi names.

[luthermonson]

Confirmed empirically (not just the earlier lib symbol-grep) against the released v0.7.3 binaries, serve mode, opcache.enable=1:

Platform	PHP 8.3 serve	PHP 8.5 serve
Linux	opcache_enabled=true	true
Windows	opcache_enabled=false	true

So the blast radius is Windows + PHP 8.3/8.4 only. Linux/macOS 8.3/8.4 carry the SAPI-allowlist patch (opcache activates); the Windows 8.3/8.4 SDK build is missing it. PHP 8.5 is unaffected everywhere (upstream removed the supported_sapis allowlist). The extension loads on the broken combo (extension_loaded('Zend OPcache')=1) but declines to activate for the unknown ephpm SAPI at MINIT.

Fix: apply the same allowlist patch in the php-sdk Windows build path for 8.3/8.4 (Linux/macOS already have it). Cheap artifact check: strings php8embed.lib | grep -i ephpm should show the SAPI name alongside frankenphp/litespeed.

[luthermonson]

This needs no php-sdk change. The build pipeline is correct and has been since 2026-07-07 (fa75a7f3, which registered the patch for buildconfForWindows as well as buildconfForUnix — Windows was never excluded). The bug is downstream: ePHPm was pinning a stale SDK.

Ground truth

Searched php8embed.lib in each released Windows tarball for the injected SAPI name, then printed the NUL-separated tail of supported_sapis[] from the "fuzzer" anchor — adjacency to fuzzer is the patch's actual signature, so this rules out the string merely occurring somewhere unrelated:

Windows SDK	allowlist tail after fuzzer
8.3.31	frankenphp | ngx-php | cli | phpdbg | micro — no ephpm
8.3.33	ephpm | embed | frankenphp | ngx-php | cli | phpdbg | micro
8.4.23	ephpm | frankenphp | ngx-php | cli | phpdbg | micro
8.4.24	ephpm present

Two corrections to this issue as filed:

1. 8.4 was never broken. The title says "8.3/8.4 SDKs". The original evidence was a symbol grep of 8.3.31 only, and the empirical follow-up table tested 8.3 and 8.5 but not 8.4. 8.4.23 — the version ePHPm actually pins — carries the patch. It was built 2026-07-11, after the patch landed.
2. 8.3.31 predates the patch, full stop. Its Windows asset was uploaded 2026-07-06; the patch landed 2026-07-07. Every later 8.3 build has it. 8.3.33 has carried it since 2026-08-02.

(8.3.33 also carries embed, because its Windows asset was rebuilt 2026-08-12 — after SPC_OPCACHE_EXTRA_SAPIS: "ephpm,embed" was introduced on 08-10. 8.4.23 predates that and injects ephpm alone, which is all ePHPm needs.)

Why it went unnoticed for three weeks

The nightly SDK Bump workflow in ephpm has been trying to land the 8.3.31 → 8.3.33 bump every night since 8.3.33 shipped, and failing at the push step:

! [remote rejected] bump/php-8.3.33 (refusing to allow a GitHub App to create or
  update workflow `.github/workflows/release.yml` without `workflows` permission)

GITHUB_TOKEN cannot modify files under .github/workflows/, and release.yml is a pin site. The failure is in a scheduled workflow, so nobody saw it. Tracked separately — it needs a credential with workflow scope.

Fix

ephpm/ephpm#373 moves the 8.3 pin to 8.3.33 (8.4 left alone deliberately). Closing this once that merges.

[luthermonson]

Fixed. ephpm/ephpm#373 moved the PHP 8.3 pin to 8.3.33, whose Windows php8embed.lib carries the OPcache supported_sapis allowlist patch.

Verified by dumping the allowlist tail from the fuzzer anchor in each shipped php8embed.lib — adjacency to fuzzer is the patch's signature, so this rules out the string merely occurring elsewhere in the library:

Windows SDK	allowlist tail after fuzzer
8.3.31 (was pinned)	frankenphp | ngx-php | cli | phpdbg | micro — no ephpm
8.3.33 (now pinned)	ephpm | embed | frankenphp | ngx-php | cli | phpdbg | micro
8.4.23 (pinned)	ephpm | frankenphp | ngx-php | cli | phpdbg | micro

Two corrections to this issue as filed, for the record:

1. 8.4 was never affected. The title says "8.3/8.4 SDKs"; the original evidence was a symbol grep of 8.3.31 only, and the follow-up empirical table covered 8.3 and 8.5 but not 8.4. 8.4.23 — the version ePHPm pins — carries the patch.
2. The php-sdk build pipeline needed no change. It has been correct since fa75a7f3 (2026-07-07), which registered the patch for buildconfForWindows as well as Unix. 8.3.31 simply predates it — its Windows asset was uploaded 2026-07-06, one day before.

The reason it went unnoticed for weeks is ephpm/ephpm#374: the nightly SDK Bump workflow generated exactly this bump every night and failed at the push, because GITHUB_TOKEN may not modify files under .github/workflows/ and release.yml is a pin site.

Landing 8.3.33 also required #49 — the gnu tarball was missing lib/libstdc++.a — fixed in #50 and re-uploaded.