# Kompilacja PHP z kodu źródłowego

> Kompilacja PHP z kodu źródłowego: wymagania, opcje configure, sprawdzanie podpisu, testy i dlaczego własne buildy oznaczają własne obowiązki dotyczące poprawek.

Źródło: https://phpsos.de/pl/php/php-kompilieren/  
Stan: 25.10.2026  
Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6

**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:

```bash
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.

```bash
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:

1. **Konfiguracja:** `./configure` z pożądanymi opcjami. Przy budowaniu z Git wcześniej wykonać `./buildconf`.
2. **Budowanie:** `make -j"$(nproc)"`; liczba zadań odpowiada według README rozsądnie liczbie rdzeni procesora.
3. **Testowanie:** `make TEST_PHP_ARGS=-j4 test` uruchamia zestaw testów PHP.
4. **Instalacja:** `make install`, zależnie od katalogu docelowego z uprawnieniami roota.

Przykład buildu PHP-FPM z własnym katalogiem docelowym:

```bash
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](https://phpsos.de/pl/php/php-erweiterungen/) oraz [SAPI wyjaśnione](https://phpsos.de/pl/php/sapi-erklaert/).

## 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:

1. Pobrać kod źródłowy wersji z poprawką i sprawdzić go.
2. Zbudować od nowa z identycznymi opcjami; `php -i` pokazuje pierwotny wiersz configure.
3. Uruchomić testy i zainstalować.
4. Zrestartować wszystkie procesy PHP, jak opisano w artykule [Restart PHP-FPM i wszystkich workerów](https://phpsos.de/pl/php2shell/php-fpm-neustart/).
5. Sprawdzić działającą wersję, jak wyjaśniono w artykule [Prawidłowe sprawdzanie wersji PHP i stanu poprawek](https://phpsos.de/pl/php2shell/php-version-pruefen/).

> **Ważne:**
> 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](https://phpsos.de/pl/leistungen/php-patch-service/) 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.

## Źródła

- [Podręcznik PHP: instalacja z kodu źródłowego](https://www.php.net/manual/en/install.unix.source.php)
- [Podręcznik PHP: opcje configure](https://www.php.net/manual/en/configure.about.php)
- [Podręcznik PHP: instalacja FPM](https://www.php.net/manual/en/install.fpm.install.php)
- [php.net: pakiety źródłowe z sumami kontrolnymi i podpisami](https://www.php.net/downloads.php)