Compiler PHP depuis le code source

En bref : compiler PHP, c'est télécharger le paquet source officiel depuis php.net, définir avec ./configure les interfaces et extensions souhaitées, construire avec make, vérifier avec make test, puis installer. Cela donne le plein contrôle de la version et du périmètre. Le prix : vous êtes vous-même responsable de chaque mise à jour de sécurité, comme récemment avec PHP2Shell, où il a fallu reconstruire et redémarrer tous les processus.

Quand des builds PHP maison sont judicieux

La plupart des serveurs obtiennent PHP depuis une source de paquets : la distribution Linux, un dépôt tiers ou une image de conteneur. C'est généralement le meilleur choix pour l'exploitation normale, car les correctifs de sécurité sont livrés automatiquement.

Les builds maison ont néanmoins leur place :

Qui opte pour des builds maison a besoin d'un processus fixe pour les mises à jour, sinon l'avantage devient un risque.

Prérequis

Selon le manuel, GNU make et un compilateur C sont nécessaires ; depuis PHP 8.4, le compilateur doit prendre en charge C11. Qui construit depuis le dépôt Git plutôt que depuis un paquet de version a en plus besoin d'autoconf (à partir de 2.68), de re2c (à partir de 1.0.3 pour PHP 8.3 et plus récent) et de bison (à partir de 3.0.0). Le README du code source donne cette entrée en matière pour Ubuntu :

sudo apt install -y pkg-config build-essential autoconf bison re2c libxml2-dev libsqlite3-dev

Pour chaque extension supplémentaire s'ajoutent les paquets de développement correspondants, par exemple pour OpenSSL ou libsodium.

Télécharger le code source et vérifier son authenticité

Un PHP construit soi-même n'est digne de confiance que dans la mesure où son code source l'est. php.net propose chaque paquet avec une somme de contrôle SHA-256 et une signature GPG ; les clés des release managers figurent sur la page de téléchargement et sur la page des clés GPG.

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                     # comparer avec la valeur sur php.net
gpg --verify php-8.4.27.tar.xz.asc php-8.4.27.tar.xz

Ce n'est que lorsque la somme de contrôle et la signature concordent qu'on poursuit.

Compiler PHP : configure, make, test

Le déroulement comporte quatre étapes :

1. Configurer : ./configure avec les options souhaitées. Pour une construction depuis Git, exécuter d'abord ./buildconf.
2. Construire : make -j"$(nproc)" ; selon le README, le nombre de jobs correspond judicieusement au nombre de cœurs du processeur.
3. Tester : make TEST_PHP_ARGS=-j4 test exécute la suite de tests de PHP.
4. Installer : make install, selon le répertoire cible avec les droits root.

Un exemple de build PHP-FPM avec son propre répertoire cible :

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

Les principales options en un coup d'œil :

Avec --prefix, plusieurs versions construites soi-même peuvent être installées côte à côte, par exemple sous /opt/php-8.3 et /opt/php-8.4. Cela facilite les transitions, mais exige de la discipline : chaque version installée est un logiciel à part entière, qui doit être reconstruit à chaque version de sécurité, même si aucun site web ne l'utilise pour le moment. Les builds qui ne sont plus nécessaires doivent être entièrement supprimés. Les options d'un build existant sont affichées par php -i à la ligne « Configure Command » ; c'est le meilleur modèle pour la prochaine reconstruction.

Remarque sur OPcache : depuis PHP 8.5, OPcache est, selon la RFC adoptée, compilé en dur. Pour les versions plus anciennes, il est construit comme extension et chargé par zend_extension. Ce que sont les extensions et les interfaces est expliqué dans Comprendre les extensions PHP et SAPI expliquée.

Builds maison et sécurité : les obligations après PHP2Shell

Un PHP compilé soi-même a un véritable avantage de sécurité : vous ne construisez que ce dont vous avez besoin. Chaque extension non construite et chaque mode d'exploitation non construit est du code qui ne peut contenir aucune faille. Un build sans CGI, avec peu d'extensions et des chemins clairs est facile à appréhender.

À cela s'oppose une obligation stricte. Pour PHP2Shell, les distributions ont livré en partie des rétroportages le 21 octobre 2026 ; qui construit lui-même ne reçoit rien automatiquement. Concrètement, cela signifiait :

1. Télécharger et vérifier le code source de la version corrigée.
2. Reconstruire avec des options identiques ; php -i affiche la ligne configure d'origine.
3. Exécuter les tests et installer.
4. Redémarrer tous les processus PHP, comme décrit sous Redémarrer PHP-FPM et tous les workers.
5. Vérifier la version en cours d'exécution, comme expliqué sous Vérifier correctement la version de PHP et le niveau de correctifs.

Comment PHP SOS aide-t-il concrètement ?

Via le service de correctifs PHP, nous accompagnons les exploitants de builds maison :

• Recenser l'existant : nous trouvons les versions de PHP construites soi-même et lisons leurs options de build.
• Reconstruire : version corrigée avec signature vérifiée, mêmes options et exécution complète des tests.
• Déployer et redémarrer : installation, redémarrage de tous les processus, contrôle de la version en cours d'exécution.
• Simplifier : là où une source de paquets entretenue remplit le même objectif, nous montrons la transition.

Questions fréquentes

Sources

• Manuel PHP : installation depuis le code source
• Manuel PHP : options de configure
• Manuel PHP : installer FPM
• php.net : paquets source avec sommes de contrôle et signatures