Krótko: Kompilacja PHP oznacza pobranie oficjalnego pakietu źródłowego z php.net, ustalenie za pomocą ./configure pożądanych interfejsów i rozszerzeń, zbudowanie przez make, sprawdzenie przez make test, a następnie instalację. Daje to pełną kontrolę nad wersją i zakresem. Cena: za każdą aktualizację bezpieczeństwa odpowiadają Państwo sami, jak ostatnio przy PHP2Shell, gdy trzeba było zbudować od nowa i zrestartować wszystkie procesy.
Kiedy własne buildy PHP mają sens
Większość serwerów pobiera PHP ze źródła pakietów: z dystrybucji Linuksa, z repozytorium podmiotu trzeciego lub przez obraz kontenera. Jest to w normalnej eksploatacji zwykle najlepszy wybór, ponieważ poprawki bezpieczeństwa są dostarczane automatycznie.
Własne buildy mają mimo to swoje miejsce:
| Sytuacja | Źródło pakietów | Własny build |
|---|---|---|
| Zwykły serwer WWW | zwykle lepsze | rzadko potrzebny |
| Wersja lub opcja niedostępna w zaufanym źródle | niedostępne | sensowny |
| Szukanie błędów w samym PHP, build debugowy | ograniczone | sensowny |
| Minimalny zakres funkcji dla specjalnych systemów | ograniczone | sensowny |
| Aktualizacje bezpieczeństwa | przychodzą ze źródłem | własne zadanie |
Kto decyduje się na własne buildy, potrzebuje stałego procesu aktualizacji, w przeciwnym razie zaleta zamienia się w ryzyko.
Wymagania
Według podręcznika potrzebne są GNU make i kompilator C; od PHP 8.4 kompilator musi obsługiwać C11. Kto buduje z repozytorium Git zamiast z pakietu wydania, potrzebuje dodatkowo autoconf (od 2.68), re2c (od 1.0.3 dla PHP 8.3 i nowszych) oraz bison (od 3.0.0). README w kodzie źródłowym podaje dla Ubuntu takie wprowadzenie:
sudo apt install -y pkg-config build-essential autoconf bison re2c libxml2-dev libsqlite3-dev
Dla każdego dodatkowego rozszerzenia dochodzą odpowiednie pakiety deweloperskie, na przykład dla OpenSSL lub libsodium.
Pobranie kodu źródłowego i sprawdzenie autentyczności
Samodzielnie zbudowane PHP jest tak zaufane, jak jego kod źródłowy. php.net oferuje każdy pakiet z sumą kontrolną SHA-256 i podpisem GPG; klucze release managerów znajdują się na stronie pobierania i na stronie z kluczami 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 # porównać z wartością na php.net
gpg --verify php-8.4.27.tar.xz.asc php-8.4.27.tar.xz
Dopiero gdy suma kontrolna i podpis się zgadzają, można iść dalej.
Kompilacja PHP: configure, make, test
Przebieg ma cztery kroki:
- Konfiguracja:
./configurez pożądanymi opcjami. Przy budowaniu z Git wcześniej wykonać./buildconf. - Budowanie:
make -j"$(nproc)"; liczba zadań odpowiada według README rozsądnie liczbie rdzeni procesora. - Testowanie:
make TEST_PHP_ARGS=-j4 testuruchamia zestaw testów PHP. - Instalacja:
make install, zależnie od katalogu docelowego z uprawnieniami roota.
Przykład buildu PHP-FPM z własnym katalogiem docelowym:
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
Najważniejsze opcje w skrócie:
| Opcja | Działanie |
|---|---|
--enable-fpm |
buduje PHP-FPM; do tego --with-fpm-user, --with-fpm-group, --with-fpm-systemd |
--with-config-file-path |
katalog, w którym PHP szuka php.ini |
--with-openssl |
obsługa OpenSSL; od PHP 7.4 ścieżka jest znajdowana przez pkg-config |
--with-sodium |
nowoczesna kryptografia z libsodium |
--disable-cgi |
rezygnuje z wariantu CGI, gdy nie jest potrzebny |
--enable-debug |
symbole debugowania, według README zalecane do programowania, nie do produkcji |
--enable-zts |
bezpieczeństwo wątkowe dla trybów pracy z wątkami |
Za pomocą --prefix można zainstalować obok siebie kilka samodzielnie zbudowanych wersji, na przykład w /opt/php-8.3 i /opt/php-8.4. Ułatwia to przełączenia, ale wymaga dyscypliny: każda zainstalowana wersja to osobne oprogramowanie, które trzeba budować od nowa przy każdym wydaniu bezpieczeństwa, nawet jeśli akurat żadna strona z niego nie korzysta. Niepotrzebne już buildy należy usunąć w całości. Jakie opcje ma istniejący build, pokazuje php -i w wierszu „Configure Command”; jest to najlepszy wzór dla następnej przebudowy.
Uwaga o OPcache: od PHP 8.5 OPcache jest według przyjętego RFC na stałe skompilowany. W starszych wersjach buduje się go jako rozszerzenie i ładuje przez zend_extension. Czym są rozszerzenia i interfejsy, wyjaśniają artykuły Rozszerzenia PHP w pigułce oraz SAPI wyjaśnione.
Własne buildy a bezpieczeństwo: obowiązki po PHP2Shell
Samodzielnie skompilowane PHP ma realną zaletę bezpieczeństwa: buduje się tylko to, czego potrzeba. Każde niezbudowane rozszerzenie i każdy niezbudowany tryb pracy to kod, który nie może zawierać luki. Build bez CGI, z kilkoma rozszerzeniami i jasnymi ścieżkami jest przejrzysty.
Przeciwwagą jest twardy obowiązek. Dystrybucje dostarczyły backporty dla PHP2Shell częściowo już 21.10.2026; kto buduje sam, nie dostaje niczego automatycznie. Konkretnie oznaczało to:
- Pobrać kod źródłowy wersji z poprawką i sprawdzić go.
- Zbudować od nowa z identycznymi opcjami;
php -ipokazuje pierwotny wiersz configure. - Uruchomić testy i zainstalować.
- Zrestartować wszystkie procesy PHP, jak opisano w artykule Restart PHP-FPM i wszystkich workerów.
- Sprawdzić działającą wersję, jak wyjaśniono w artykule Prawidłowe sprawdzanie wersji PHP i stanu poprawek.
Samodzielnie zbudowane PHP nie pojawia się w żadnym menedżerze pakietów. Proszę prowadzić inwentarz, na których serwerach działają własne buildy w jakiej wersji, w przeciwnym razie przy następnej luce zostaną przeoczone.
Jak konkretnie pomaga PHP SOS?
Dzięki usłudze poprawek PHP wspieramy operatorów własnych buildów:
- Inwentaryzacja: Znajdujemy samodzielnie zbudowane wersje PHP i odczytujemy ich opcje budowania.
- Ponowne budowanie: Wersja z poprawką ze sprawdzonym podpisem, tymi samymi opcjami i pełnym przebiegiem testów.
- Wdrożenie i restart: Instalacja, restart wszystkich procesów, kontrola działającej wersji.
- Uproszczenie: Tam, gdzie utrzymywane źródło pakietów spełnia ten sam cel, pokazujemy przejście na nie.
Częste pytania
Kiedy opłaca się samodzielnie kompilować PHP?
Gdy potrzebna wersja lub opcja nie jest dostępna w żadnym zaufanym źródle pakietów, do programowania i szukania błędów w samym PHP albo do bardzo odchudzonych, specjalnych buildów. Dla zwykłych serwerów WWW utrzymywane pakiety są zwykle lepszym wyborem.
Jak sprawdzić, że kod źródłowy PHP jest autentyczny?
php.net oferuje dla każdego pakietu źródłowego sumę kontrolną SHA-256 i podpis GPG. Proszę porównać sumę kontrolną i sprawdzić podpis kluczami release managerów opublikowanymi na php.net.
Czy po wydaniu bezpieczeństwa muszę kompilować od nowa?
Tak. Samodzielnie zbudowane PHP nie otrzymuje aktualizacji z dystrybucji. Po PHP2Shell oznaczało to: zbudować kod źródłowy wersji 8.5.12, 8.4.27, 8.3.36 lub 8.2.35, zainstalować go i zrestartować wszystkie procesy PHP.
Gdzie znajdę wszystkie opcje configure?
Za pomocą ./configure --help w katalogu źródłowym. Podręcznik wymienia najważniejsze opcje rdzenia, a opcje rozszerzeń znajdują się na ich stronach podręcznika.