Kurz gesagt: PHP zu kompilieren heißt, das offizielle Quellpaket von php.net herunterzuladen, mit ./configure die gewünschten Schnittstellen und Erweiterungen festzulegen, mit make zu bauen, mit make test zu prüfen und dann zu installieren. Das gibt volle Kontrolle über Version und Umfang. Der Preis: Für jedes Sicherheitsupdate sind Sie selbst zuständig, wie zuletzt bei PHP2Shell, als neu gebaut und alle Prozesse neu gestartet werden mussten.
Wann eigene PHP-Builds sinnvoll sind
Die meisten Server beziehen PHP aus einer Paketquelle: aus der Linux-Distribution, einem Drittanbieter-Repository oder über ein Container-Image. Das ist für den normalen Betrieb meist die beste Wahl, weil Sicherheitskorrekturen automatisch nachgeliefert werden.
Eigene Builds haben trotzdem ihren Platz:
| Situation | Paketquelle | Eigener Build |
|---|---|---|
| Normaler Webserver | meist besser | selten nötig |
| Version oder Option nicht in vertrauenswürdiger Quelle | nicht verfügbar | sinnvoll |
| Fehlersuche an PHP selbst, Debug-Build | eingeschränkt | sinnvoll |
| Minimaler Funktionsumfang für spezielle Systeme | eingeschränkt | sinnvoll |
| Sicherheitsupdates | kommen mit der Quelle | eigene Aufgabe |
Wer sich für eigene Builds entscheidet, braucht einen festen Prozess für Updates, sonst wird der Vorteil zum Risiko.
Voraussetzungen
Laut Handbuch werden GNU make und ein C-Compiler benötigt; seit PHP 8.4 muss der Compiler C11 unterstützen. Wer aus dem Git-Repository statt aus einem Release-Paket baut, braucht zusätzlich autoconf (ab 2.68), re2c (ab 1.0.3 für PHP 8.3 und neuer) und bison (ab 3.0.0). Die README im Quellcode nennt für Ubuntu diesen Einstieg:
sudo apt install -y pkg-config build-essential autoconf bison re2c libxml2-dev libsqlite3-dev
Für jede zusätzliche Erweiterung kommen die passenden Entwicklungspakete hinzu, etwa für OpenSSL oder libsodium.
Quellcode laden und Echtheit prüfen
Ein selbst gebautes PHP ist nur so vertrauenswürdig wie sein Quellcode. php.net bietet jedes Paket mit SHA-256-Prüfsumme und GPG-Signatur an; die Schlüssel der Release-Manager stehen auf der Download-Seite und der Seite mit den GPG-Schlüsseln.
curl -O https://www.php.net/distributions/php-8.4.27.tar.xz
curl -O https://www.php.net/distributions/php-8.4.27.tar.xz.asc
sha256sum php-8.4.27.tar.xz # mit dem Wert auf php.net vergleichen
gpg --verify php-8.4.27.tar.xz.asc php-8.4.27.tar.xz
Erst wenn Prüfsumme und Signatur stimmen, geht es weiter.
PHP kompilieren: configure, make, test
Der Ablauf hat vier Schritte:
- Konfigurieren:
./configuremit den gewünschten Optionen. Beim Bau aus Git vorher./buildconfausführen. - Bauen:
make -j"$(nproc)"; die Zahl der Jobs entspricht laut README sinnvollerweise der Zahl der Prozessorkerne. - Testen:
make TEST_PHP_ARGS=-j4 testführt die Testsuite von PHP aus. - Installieren:
make install, je nach Zielverzeichnis mit Root-Rechten.
Ein Beispiel für einen PHP-FPM-Build mit eigenem Zielverzeichnis:
tar xf php-8.4.27.tar.xz && cd php-8.4.27
./configure --prefix=/opt/php-8.4 \
--with-config-file-path=/opt/php-8.4/etc \
--enable-fpm --with-fpm-user=www-data --with-fpm-group=www-data --with-fpm-systemd \
--with-openssl --with-sodium \
--disable-cgi
make -j"$(nproc)"
make TEST_PHP_ARGS=-j4 test
sudo make install
/opt/php-8.4/bin/php -v
Die wichtigsten Optionen im Überblick:
| Option | Wirkung |
|---|---|
--enable-fpm |
baut PHP-FPM; dazu --with-fpm-user, --with-fpm-group, --with-fpm-systemd |
--with-config-file-path |
Verzeichnis, in dem PHP die php.ini sucht |
--with-openssl |
OpenSSL-Unterstützung; seit PHP 7.4 wird der Pfad über pkg-config gefunden |
--with-sodium |
moderne Kryptografie mit libsodium |
--disable-cgi |
verzichtet auf die CGI-Variante, wenn sie nicht gebraucht wird |
--enable-debug |
Debug-Symbole, laut README für Entwicklung empfohlen, nicht für Produktion |
--enable-zts |
Thread-Sicherheit für Betriebsarten mit Threads |
Mit --prefix lassen sich mehrere selbst gebaute Versionen nebeneinander installieren, etwa unter /opt/php-8.3 und /opt/php-8.4. Das erleichtert Umstellungen, verlangt aber Disziplin: Jede installierte Version ist eigene Software, die bei jedem Sicherheitsrelease neu gebaut werden muss, auch wenn gerade keine Website sie nutzt. Nicht mehr benötigte Builds gehören vollständig entfernt. Welche Optionen ein vorhandener Build hat, zeigt php -i in der Zeile „Configure Command“; sie ist die beste Vorlage für den nächsten Neubau.
Hinweis zu OPcache: Seit PHP 8.5 ist OPcache laut angenommenem RFC fest einkompiliert. Bei älteren Versionen wird es als Erweiterung gebaut und per zend_extension geladen. Was Erweiterungen und Schnittstellen sind, erklären PHP-Erweiterungen verstehen und SAPI erklärt.
Eigene Builds und Sicherheit: die Pflichten nach PHP2Shell
Selbst kompiliertes PHP hat einen echten Sicherheitsvorteil: Sie bauen nur, was Sie brauchen. Jede nicht gebaute Erweiterung und jede nicht gebaute Betriebsart ist Code, der keine Lücke enthalten kann. Ein Build ohne CGI, mit wenigen Erweiterungen und klaren Pfaden ist übersichtlich.
Dem steht eine harte Pflicht gegenüber. Distributionen haben bei PHP2Shell Backports teils am 21.10.2026 ausgeliefert; wer selbst baut, bekommt nichts automatisch. Konkret hieß das:
- Quellcode der Fix-Version laden und prüfen.
- Mit identischen Optionen neu bauen;
php -izeigt die ursprüngliche configure-Zeile. - Tests ausführen und installieren.
- Alle PHP-Prozesse neu starten, wie unter PHP-FPM und alle Worker neu starten beschrieben.
- Laufende Version prüfen, wie unter PHP-Version und Patchstand richtig prüfen erklärt.
Ein selbst gebautes PHP taucht in keinem Paketmanager auf. Führen Sie ein Inventar, auf welchen Servern eigene Builds in welcher Version laufen, sonst werden sie bei der nächsten Lücke übersehen.
Wie hilft PHP SOS konkret?
Über den PHP-Patch-Service unterstützen wir Betreiber eigener Builds:
- Bestand erfassen: Wir finden selbst gebaute PHP-Versionen und lesen ihre Build-Optionen aus.
- Neu bauen: Fix-Version mit geprüfter Signatur, gleichen Optionen und vollständigem Testlauf.
- Ausrollen und neu starten: Installation, Neustart aller Prozesse, Kontrolle der laufenden Version.
- Vereinfachen: Wo eine gepflegte Paketquelle denselben Zweck erfüllt, zeigen wir den Umstieg auf.
Häufige Fragen
Wann lohnt es sich, PHP selbst zu kompilieren?
Wenn eine benötigte Version oder Option in keiner vertrauenswürdigen Paketquelle verfügbar ist, für Entwicklung und Fehlersuche an PHP selbst oder für sehr schlanke, spezielle Builds. Für normale Webserver sind gepflegte Pakete meist die bessere Wahl.
Wie prüfe ich, dass der PHP-Quellcode echt ist?
php.net bietet zu jedem Quellpaket eine SHA-256-Prüfsumme und eine GPG-Signatur an. Vergleichen Sie die Prüfsumme und prüfen Sie die Signatur mit den auf php.net veröffentlichten Schlüsseln der Release-Manager.
Muss ich nach einem Sicherheitsrelease neu kompilieren?
Ja. Ein selbst gebautes PHP erhält keine Updates von der Distribution. Nach PHP2Shell hieß das: Quellcode von 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 bauen, installieren und alle PHP-Prozesse neu starten.
Wo finde ich alle configure-Optionen?
Mit ./configure --help im Quellverzeichnis. Das Handbuch nennt die wichtigsten Kernoptionen, Optionen für Erweiterungen stehen auf deren Handbuchseiten.