8.3.33 linux-x86_64-gnu tarball is missing lib/libstdc++.a — static links fail on ICU's C++ symbols

[luthermonson]

php-sdk-8.3.33-linux-x86_64-gnu.tar.gz does not contain lib/libstdc++.a. Every neighbouring release does. ICU still ships in the same tarball, and ICU is C++, so anything linking this SDK statically fails with undefined C++ runtime symbols.

Evidence

Listing archive members of the released Linux tarballs:

Linux SDK	libstdc++.a	libicuuc.a	total .a in lib/
8.3.31	present	present	38
8.3.33	absent	present	37
8.4.23	present	present	38
8.4.24	present	present	38

Exactly one file, only in this release.

Downstream failure

ePHPm's crates/ephpm-php/build.rs links the bundled archive when it finds it:

warning: ephpm-php@0.1.0: probe libstdc++.a at .../php-sdk/8.3.33-linux-x86_64-gnu/lib/libstdc++.a: found=false

and then the link dies:

rust-lld: error: undefined symbol: operator new(unsigned long)
rust-lld: error: undefined symbol: __cxa_begin_catch
rust-lld: error: undefined symbol: __gxx_personality_v0
rust-lld: error: undefined symbol: vtable for __cxxabiv1::__si_class_type_info
rust-lld: error: undefined symbol: std::condition_variable::condition_variable()
rust-lld: error: too many errors emitted, stopping now

Reproduced in CI on ephpm/ephpm#373, which does nothing but move the 8.3 pin from 8.3.31 to 8.3.33. Same code, same build.rs, only the SDK version differs — 8.3.31 links clean.

Why it matters right now

8.3.33 is the release ePHPm needs in order to fix #47 — Windows PHP 8.3 builds currently run with OPcache silently disabled, and 8.3.33 is the oldest 8.3 SDK carrying the supported_sapis allowlist patch. This regression is the only thing blocking that fix, since the pin is per-minor and cannot be set per-platform.

Note on intent

This looks unintentional rather than a deliberate change: bundling libstdc++ is documented behaviour in the tarball's own THIRD-PARTY-NOTICES.txt ("Bundled so consumers link the same C++ runtime static-php-cli compiled ICU and libxml2 against"), and dropping it while keeping ICU leaves the tarball internally inconsistent. If it was deliberate, the notices file and the consumer guidance need updating too, and consumers need a documented way to supply their own C++ runtime.

Suggested fix

Rebuild the 8.3.33 linux-x86_64-gnu lane (and check linux-aarch64-gnu, plus the musl linux-* variants, which were not inspected here) so libstdc++.a is staged into lib/ as it is for 8.3.31 / 8.4.23 / 8.4.24.

Worth adding a completeness assertion to the packaging step: the Linux Package SDK job could fail if libicuuc.a is present without libstdc++.a, which is exactly the inconsistent state shipped here.

References

• Windows 8.3/8.4 SDKs: php8embed.lib missing the ephpm OPcache SAPI-allowlist patch - OPcache never activates in serve mode #47 — the Windows OPcache miss that needs 8.3.33
• fix(build): pin PHP 8.3 to 8.3.33 — Windows OPcache was silently off (php-sdk#47) ephpm#373 — the blocked pin bump; CI run reproducing the link failure

[luthermonson]

Corrected root cause and blast radius — both wider than filed.

Cause is not a missing copy step. The container staging script runs under set -eux and staged libstdc++.a last, after an x86_64-only intrinsics guard added in 43267a7 (2026-07-09). That guard aborts the script, so the staging never runs. Two independent abort paths, both confirmed against shipped artifacts:

• HAVE_FUNC_ATTRIBUTE_TARGET is /* #undef */ in every Alpine x86_64 build — the CFLAGS override works on almalinux and never has on Alpine.
• SHA256_Transform_shani entered php-src in 8.4, so the nm assertion fails on all of 8.3.

aarch64 skips the guard entirely, which is why every aarch64 tarball is intact. The regression starts at 43267a7, not at the 8.3.33 build.

Why CI stayed green: a container-side abort does not fail the job — docker run exiting non-zero doesn't stop the step, and mkdir -p /output runs before the guards, so an aborted script still yields a green job and a short tarball. That is the real defect; the missing file is one symptom.

Affected (verified by listing published tarball members):

Variant	Missing libstdc++.a
linux-x86_64-gnu	8.3.32, 8.3.33
linux-x86_64 (musl)	8.3.32, 8.3.33, 8.4.23, 8.4.24, 8.5.8, 8.5.9

Intact: all aarch64, linux-x86_64-gnu on 8.4/8.5, 8.4.24-linux-x86_64-gnu-nts, everything pre-2026-07-09. My original table only checked -gnu and so missed the musl breakage entirely.

Secondary: those tarballs' bin/php-config --libs omits -lstdc++, and THIRD-PARTY-NOTICES.txt advertises a bundled libstdc++ that isn't there.

Fix in #50, validated behind release_tag_suffix=-libstdcxxfix (38 archives, only delta is + ./lib/libstdc++.a).