The musl x86_64 SDKs have shipped without SHA-NI / PCLMUL / AVX2 resolvers continuously since 8.3.31. The CFLAGS override intended to enable them works on almalinux and has never worked on Alpine.
Found while root-causing #49; independent of it, and not fixed by #50.
Evidence
php_config.h in the shipped linux-x86_64 (musl) tarballs contains:
/* #undef HAVE_FUNC_ATTRIBUTE_TARGET */
Verified in 8.3.31, 8.3.33 and 8.5.9 — i.e. every musl x86_64 build since the override was introduced in 43267a7 (2026-07-09), and before it too. Without HAVE_FUNC_ATTRIBUTE_TARGET, PHP cannot compile the __attribute__((target(...))) function multiversioning that the hardware-accelerated implementations rely on, so the build silently falls back to portable C for:
- SHA-NI (
SHA256_Transform_shani — absent from the musl libphp.a)
- PCLMUL (CRC32)
- AVX2 paths
The glibc (-gnu) builds are unaffected — the same override does apply on almalinux, and HAVE_FUNC_ATTRIBUTE_TARGET is defined there.
Impact
Anything consuming the musl SDK gets measurably slower hashing and CRC32 with no indication anything is wrong. It is a pure performance regression, not a correctness one, which is exactly why it went unnoticed for six weeks — nothing fails, it is just slower than the glibc build for no stated reason.
Note ePHPm itself is not affected: it links the -gnu SDK on Linux (see its CLAUDE.md — the release targets <arch>-unknown-linux-gnu against the glibc libphp.a). This bites other consumers of the musl tarballs.
Current state after #50
#50 converts this from a silent truncation into a visible signal: HAVE_FUNC_ATTRIBUTE_TARGET undefined is now a hard error on glibc and a ::warning:: on musl. Deliberately a warning there so musl builds keep shipping while this is unfixed — but that warning will now appear on every musl x86_64 build until it is.
What to investigate
Why the CFLAGS override doesn't take on Alpine. Candidates worth checking in order: whether the flags reach ./configure at all in the Alpine container (versus being overwritten by spc's own CFLAGS handling), whether Alpine's gcc/musl toolchain rejects the specific attribute probe PHP's configure uses, and whether the probe fails for an unrelated reason (missing header, -Werror in the probe) that makes configure conclude the attribute is unsupported.
The cheap first step is to run the failing configure probe by hand inside the Alpine build container and read config.log — it records exactly why the test compiled or didn't.
References
The musl x86_64 SDKs have shipped without SHA-NI / PCLMUL / AVX2 resolvers continuously since 8.3.31. The CFLAGS override intended to enable them works on almalinux and has never worked on Alpine.
Found while root-causing #49; independent of it, and not fixed by #50.
Evidence
php_config.hin the shippedlinux-x86_64(musl) tarballs contains:Verified in 8.3.31, 8.3.33 and 8.5.9 — i.e. every musl x86_64 build since the override was introduced in
43267a7(2026-07-09), and before it too. WithoutHAVE_FUNC_ATTRIBUTE_TARGET, PHP cannot compile the__attribute__((target(...)))function multiversioning that the hardware-accelerated implementations rely on, so the build silently falls back to portable C for:SHA256_Transform_shani— absent from the musllibphp.a)The glibc (
-gnu) builds are unaffected — the same override does apply on almalinux, andHAVE_FUNC_ATTRIBUTE_TARGETis defined there.Impact
Anything consuming the musl SDK gets measurably slower hashing and CRC32 with no indication anything is wrong. It is a pure performance regression, not a correctness one, which is exactly why it went unnoticed for six weeks — nothing fails, it is just slower than the glibc build for no stated reason.
Note ePHPm itself is not affected: it links the
-gnuSDK on Linux (see itsCLAUDE.md— the release targets<arch>-unknown-linux-gnuagainst the glibclibphp.a). This bites other consumers of the musl tarballs.Current state after #50
#50 converts this from a silent truncation into a visible signal:
HAVE_FUNC_ATTRIBUTE_TARGETundefined is now a hard error on glibc and a::warning::on musl. Deliberately a warning there so musl builds keep shipping while this is unfixed — but that warning will now appear on every musl x86_64 build until it is.What to investigate
Why the CFLAGS override doesn't take on Alpine. Candidates worth checking in order: whether the flags reach
./configureat all in the Alpine container (versus being overwritten by spc's own CFLAGS handling), whether Alpine's gcc/musl toolchain rejects the specific attribute probe PHP's configure uses, and whether the probe fails for an unrelated reason (missing header,-Werrorin the probe) that makes configure conclude the attribute is unsupported.The cheap first step is to run the failing
configureprobe by hand inside the Alpine build container and readconfig.log— it records exactly why the test compiled or didn't.References
libstdc++.aregression this surfaced alongside43267a7(2026-07-09) — introduced the CFLAGS override and the x86_64 intrinsics guard