Компилиране на PHP от изходния код

Накратко: Да се компилира PHP означава да се изтегли официалният пакет с изходен код от php.net, с ./configure да се определят желаните интерфейси и разширения, да се изгради с make, да се провери с make test и след това да се инсталира. Това дава пълен контрол върху версията и обема. Цената: за всяка актуализация за сигурност отговаряте Вие сами, както последно при PHP2Shell, когато трябваше да се изгради наново и всички процеси да се рестартират.

Кога собствените билдове на PHP са смислени

Повечето сървъри получават PHP от източник на пакети: от Linux дистрибуцията, от хранилище на трета страна или чрез образ на контейнер. За нормалната експлоатация това обикновено е най-добрият избор, защото корекциите за сигурност се доставят автоматично.

Собствените билдове въпреки това имат своето място:

Който се реши за собствени билдове, се нуждае от твърд процес за актуализации, иначе предимството става риск.

Предпоставки

Според ръководството са нужни GNU make и C компилатор; от PHP 8.4 компилаторът трябва да поддържа C11. Който изгражда от git хранилището, а не от пакет на изданието, се нуждае допълнително от autoconf (от 2.68), re2c (от 1.0.3 за PHP 8.3 и по-нови) и bison (от 3.0.0). README в изходния код посочва за Ubuntu това начало:

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

За всяко допълнително разширение се добавят подходящите пакети за разработка, например за OpenSSL или libsodium.

Изтегляне на изходния код и проверка на автентичността

Самостоятелно изграденият PHP е толкова надежден, колкото е надежден изходният му код. php.net предлага всеки пакет със SHA-256 контролна сума и GPG подпис; ключовете на release мениджърите са на страницата за изтегляне и на страницата с 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                     # сравнете със стойността на php.net
gpg --verify php-8.4.27.tar.xz.asc php-8.4.27.tar.xz

Едва когато контролната сума и подписът съвпадат, се продължава.

Компилиране на PHP: configure, make, test

Процесът има четири стъпки:

1. Конфигуриране: ./configure с желаните опции. При изграждане от git преди това се изпълнява ./buildconf.
2. Изграждане: make -j"$(nproc)"; броят на задачите според README разумно съответства на броя на ядрата на процесора.
3. Тестване: make TEST_PHP_ARGS=-j4 test изпълнява тестовия пакет на PHP.
4. Инсталиране: make install, според целевата директория с root права.

Пример за билд на PHP-FPM със собствена целева директория:

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

Най-важните опции накратко:

С --prefix няколко самостоятелно изградени версии могат да се инсталират една до друга, например под /opt/php-8.3 и /opt/php-8.4. Това улеснява преминаванията, но изисква дисциплина: всяка инсталирана версия е отделен софтуер, който трябва да се изгражда наново при всяко издание за сигурност, дори когато в момента никой уебсайт не я ползва. Билдовете, които вече не са нужни, трябва да се премахват напълно. Кои опции има един наличен билд, показва php -i в реда „Configure Command“; той е най-добрият шаблон за следващото изграждане.

Бележка за OPcache: от PHP 8.5, според приетия RFC, OPcache е неотменно компилиран. При по-старите версии той се изгражда като разширение и се зарежда с zend_extension. Какво са разширенията и интерфейсите, обясняват Разбиране на разширенията на PHP и SAPI, обяснен.

Собствени билдове и сигурност: задълженията след PHP2Shell

Самостоятелно компилираният PHP има реално предимство за сигурността: изграждате само онова, което Ви трябва. Всяко неизградено разширение и всеки неизграден режим на работа е код, който не може да съдържа уязвимост. Билд без CGI, с малко разширения и ясни пътища е прегледен.

Срещу това стои твърдо задължение. Дистрибуциите при PHP2Shell доставиха backport отчасти на 21.10.2026 г.; който изгражда сам, не получава нищо автоматично. Конкретно това означаваше:

1. Да се изтегли и провери изходният код на коригираната версия.
2. Да се изгради наново със същите опции; php -i показва първоначалния ред на configure.
3. Да се изпълнят тестовете и да се инсталира.
4. Да се рестартират всички PHP процеси, както е описано в Рестартиране на PHP-FPM и на всички worker процеси.
5. Да се провери работещата версия, както е обяснено в Правилна проверка на версията на PHP и състоянието на пачовете.

Как помага PHP SOS конкретно?

Чрез услугата за PHP пачове подпомагаме операторите на собствени билдове:

• Описване на наличното: Намираме самостоятелно изградените версии на PHP и четем опциите на билда им.
• Ново изграждане: Коригирана версия с проверен подпис, същите опции и пълно тестово изпълнение.
• Внедряване и рестартиране: Инсталиране, рестартиране на всички процеси, проверка на работещата версия.
• Опростяване: Където поддържан източник на пакети изпълнява същата цел, показваме прехода.

Често задавани въпроси

Източници

• Ръководство на PHP: Инсталиране от изходния код
• Ръководство на PHP: Опции на configure
• Ръководство на PHP: Инсталиране на FPM
• php.net: Пакети с изходен код с контролни суми и подписи