Сборка PHP

В этой главе объясняется, как скомпилировать PHP таким образом, чтобы это подходило для разработки расширений или модификаций ядра. Мы рассмотрим только сборку на Unix-подобных системах. Если вы хотите собрать PHP на Windows, взгляните на step-by-step build instructions в wiki PHP [1].

Эта глава также даёт общее представление о том, как работает система сборки PHP и какие инструменты она использует, но подробное описание выходит за рамки этой книги.

Почему не использовать пакеты?

Если вы сейчас используете PHP, вы, вероятно, установили его через менеджер пакетов, с помощью команды вроде sudo apt-get install php. Прежде чем объяснять саму компиляцию, нужно сначала понять, почему необходимо выполнять собственную компиляцию и почему нельзя просто использовать готовый пакет. На это есть несколько причин:

Во-первых, готовый пакет содержит только итоговые бинарные файлы, но не содержит других вещей, необходимых для компиляции расширений, например заголовочных файлов. Это легко исправить, установив пакет для разработки, который обычно называется php-dev. Для упрощения отладки с помощью valgrind или gdb можно дополнительно установить debug-символы, которые обычно доступны в виде ещё одного пакета — php-dbg.

Но даже если вы установите заголовочные файлы и debug-символы, вы всё равно будете работать с release-сборкой PHP. Это означает, что она собрана с высоким уровнем оптимизации, что может сильно затруднить отладку. Кроме того, в release-сборках не включены assertions и не генерируются предупреждения об утечках памяти. Также готовые пакеты не включают потокобезопасность, которая может быть полезна, чтобы убедиться, что ваше расширение собирается в потокобезопасной конфигурации.

Другая проблема в том, что почти все дистрибутивы применяют к PHP дополнительные патчи. В некоторых случаях эти патчи содержат лишь незначительные изменения, связанные с конфигурацией, но некоторые дистрибутивы используют весьма инвазивные патчи, такие как Suhosin. Известно, что некоторые из этих патчей вызывают несовместимость с низкоуровневыми расширениями, такими как opcache.

PHP предоставляет поддержку только для программного обеспечения, предоставленного на php.net, а не для версий, изменённых дистрибутивами. Если вы хотите сообщить об ошибках, отправить патчи или воспользоваться нашими каналами помощи по написанию расширений, вам всегда следует работать с официальной версией PHP. Когда в этой книге мы говорим «PHP», мы всегда имеем в виду официально поддерживаемую версию.

Получение исходного кода

Прежде чем собрать PHP, вам нужно получить его исходный код. Это можно сделать двумя способами: либо скачать архив с PHP’s download page, либо клонировать git-репозиторий с Github.

Процесс сборки немного отличается в обоих случаях: git-репозиторий не содержит в комплекте скрипт configure, поэтому вам нужно будет сгенерировать его с помощью скрипта buildconf, который использует autoconf. Кроме того, git-репозиторий не содержит заранее сгенерированных лексера и парсера, поэтому вам также потребуется установить re2c и bison.

Мы рекомендуем получать исходный код из git, поскольку это даёт простой способ поддерживать вашу установку в актуальном состоянии и пробовать свой код с разными версиями. Git-чекаут также требуется, если вы хотите отправлять патчи или pull request’ы для PHP.

Чтобы клонировать репозиторий, выполните следующие команды в своей оболочке:

~> git clone https://github.com/php/php-src.git
~> cd php-src
# by default you will be on the master branch, which is the current
# development version. You can check out a stable branch instead:
~/php-src> git checkout PHP-8.1

Если у вас возникли проблемы с git-чекаутом, посмотрите Git FAQ в wiki PHP. Git FAQ также объясняет, как настроить git, если вы хотите вносить вклад в сам PHP. Кроме того, он содержит инструкции по настройке нескольких рабочих директорий для разных версий PHP. Это может быть очень полезно, если вам нужно тестировать свои расширения или изменения на нескольких версиях и конфигурациях PHP.

Перед тем как продолжить, вам также следует установить несколько базовых зависимостей для сборки с помощью менеджера пакетов (первые три, вероятно, у вас уже установлены по умолчанию):

  • gcc и g++ или другой набор инструментов компилятора.

  • libc-dev, который предоставляет стандартную библиотеку C, включая заголовочные файлы.

  • make — инструмент управления сборкой, который использует PHP.

  • autoconf, который используется для генерации скрипта configure.

    • 2.59 или выше (для PHP 7.0-7.1)

    • 2.64 или выше (для PHP 7.2)

    • 2.68 или выше (для PHP 7.3 и выше)

  • libtool, который помогает управлять разделяемыми библиотеками.

  • bison, который используется для генерации парсера PHP.

    • 2.4 или выше (для PHP 7.0-7.3)

    • 3.0 или выше (для PHP 7.4 и выше)

  • re2c, который используется для генерации лексера PHP.

    • Опционален для PHP <= 7.3.

    • 0.13.4 или выше (для PHP 7.4 и выше)

В Debian/Ubuntu все эти пакеты можно установить следующей командой:

~/php-src> sudo apt-get install build-essential autoconf libtool bison re2c pkg-config

В зависимости от расширений, которые вы включите на этапе ./configure, PHP потребуется ряд дополнительных библиотек. При их установке проверьте, есть ли версия пакета с окончанием -dev или -devel, и устанавливайте именно её. Пакеты без dev обычно не содержат необходимых заголовочных файлов. Например, стандартная сборка PHP потребует libxml и libsqlite3, которые можно установить через пакеты libxml2-dev и libsqlite3-dev.

Обзор сборки

Прежде чем подробнее рассмотреть, что делает каждый отдельный шаг сборки, вот команды, которые нужно выполнить для «стандартной» сборки PHP:

~/php-src> ./buildconf     # only necessary if building from git
~/php-src> ./configure
~/php-src> make -jN

Для быстрой сборки замените N на количество доступных ядер CPU (чтобы узнать это количество, можно выполнить nproc).

По умолчанию PHP собирает бинарные файлы для SAPI CLI и CGI, которые будут расположены в sapi/cli/php и sapi/cgi/php-cgi соответственно. Чтобы проверить, что всё прошло успешно, попробуйте выполнить sapi/cli/php -v.

Кроме того, вы можете выполнить sudo make install, чтобы установить PHP в /usr/local. Целевую директорию можно изменить, указав --prefix на этапе конфигурирования:

~/php-src> ./configure --prefix=$HOME/myphp
~/php-src> make -jN
~/php-src> make install

Здесь $HOME/myphp — это место установки, которое будет использоваться на этапе make install. Обратите внимание, что установка PHP не обязательна, но может быть удобна, если вы хотите использовать свою сборку PHP вне разработки расширений.

А теперь подробнее рассмотрим отдельные шаги сборки!

Скрипт ./buildconf

Если вы собираете из git-репозитория, первым делом нужно выполнить скрипт ./buildconf. Этот скрипт делает немногим больше, чем вызов makefile’а build/build.mk, который в свою очередь вызывает build/build2.mk.

Основная задача этих makefile’ов — запустить autoconf для генерации скрипта ./configure и autoheader для генерации шаблона main/php_config.h.in. Этот последний файл будет использован configure для генерации итогового заголовочного файла конфигурации main/php_config.h.

Обе утилиты получают результаты из файла configure.ac (который определяет большую часть процесса сборки PHP), файла build/php.m4 (который определяет большое количество специфичных для PHP M4-макросов) и файлов config.m4 отдельных расширений и SAPI (а также из ряда других m4-файлов).

Хорошая новость в том, что написание расширений или даже модификация ядра не потребуют активного взаимодействия с системой сборки. В дальнейшем вам придётся писать небольшие файлы config.m4, но обычно они используют лишь два-три высокоуровневых макроса, предоставляемых build/php.m4. Поэтому здесь мы не будем углубляться в подробности.

У скрипта ./buildconf есть только две опции: --debug отключает подавление предупреждений при вызове autoconf и autoheader. Если вы не планируете работать над системой сборки, эта опция вряд ли вас заинтересует.

Вторая опция — --force, которая позволяет выполнять ./buildconf в release-пакетах (например, если вы скачали упакованный исходный код и хотите сгенерировать новый ./configure), а также дополнительно очищает кеши конфигурации config.cache и autom4te.cache/.

Если вы обновляете свой git-репозиторий с помощью git pull (или другой команды) и получаете странные ошибки на этапе make, это обычно означает, что что-то изменилось в конфигурации сборки, и вам нужно повторно выполнить ./buildconf.

Скрипт ./configure

После генерации скрипта ./configure вы можете использовать его для настройки своей сборки PHP. Все поддерживаемые опции можно вывести с помощью --help:

~/php-src> ./configure --help | less

В первой части справки перечислены различные общие опции, поддерживаемые всеми скриптами конфигурации на основе autoconf. Одна из них — уже упомянутая --prefix=DIR, которая меняет директорию установки, используемую make install. Другая полезная опция — -C, которая кеширует результаты различных тестов в файле config.cache и ускоряет последующие вызовы ./configure. Использование этой опции имеет смысл только тогда, когда у вас уже есть работающая сборка и вы хотите быстро переключаться между разными конфигурациями.

Помимо общих опций autoconf, есть также множество настроек, специфичных для PHP. Например, вы можете выбрать, какие расширения и SAPI должны компилироваться, с помощью переключателей --enable-NAME и --disable-NAME. Если расширение или SAPI имеет внешние зависимости, вместо этого нужно использовать --with-NAME и --without-NAME.

Если библиотека, необходимая для NAME, не находится в стандартном месте (например, потому что вы скомпилировали её сами), некоторые расширения позволяют указать её расположение с помощью --with-NAME=DIR. Однако начиная с PHP 7.4 большинство расширений вместо этого используют pkg-config, и в этом случае передача директории в --with не даёт эффекта. В этом случае нужно добавить библиотеку в PKG_CONFIG_PATH:

export PKG_CONFIG_PATH=/path/to/library/lib/pkgconfig:$PKG_CONFIG_PATH

По умолчанию PHP собирает SAPI CLI и CGI, а также ряд расширений. Узнать, какие расширения содержит ваш бинарный файл PHP, можно с помощью опции -m. Для стандартной сборки PHP 7.0 результат будет выглядеть так:

~/php-src> sapi/cli/php -m
[PHP Modules]
Core
ctype
date
dom
fileinfo
filter
hash
iconv
json
libxml
pcre
PDO
pdo_sqlite
Phar
posix
Reflection
session
SimpleXML
SPL
sqlite3
standard
tokenizer
xml
xmlreader
xmlwriter

Если теперь вы хотите прекратить компилировать SAPI CGI, а также расширения tokenizer и sqlite3, и вместо этого включить opcache и gmp, соответствующая команда configure будет такой:

~/php-src> ./configure --disable-cgi --disable-tokenizer --without-sqlite3 \
                       --enable-opcache --with-gmp

По умолчанию большинство расширений компилируются статически, то есть становятся частью итогового бинарного файла. Только расширение opcache является общим (shared) по умолчанию, то есть генерирует разделяемый объект opcache.so в директории modules/. Вы также можете компилировать другие расширения в разделяемые объекты, указав --enable-NAME=shared или --with-NAME=shared (но это поддерживают не все расширения). О том, как использовать разделяемые расширения, мы поговорим в следующем разделе.

Чтобы узнать, какой переключатель нужно использовать и включено ли расширение по умолчанию, посмотрите ./configure --help. Если переключатель — --enable-NAME или --with-NAME, это означает, что расширение не компилируется по умолчанию и должно быть явно включено. --disable-NAME или --without-NAME, напротив, указывают на расширение, которое компилируется по умолчанию, но может быть явно отключено.

Некоторые расширения компилируются всегда и не могут быть отключены. Чтобы создать сборку, содержащую минимальное количество расширений, используйте опцию --disable-all:

~/php-src> ./configure --disable-all && make -jN
~/php-src> sapi/cli/php -m
[PHP Modules]
Core
date
hash
json
pcre
Reflection
SPL
standard

Опция --disable-all очень полезна, если вам нужна быстрая сборка и не требуется много функциональности (например, при реализации изменений в языке). Для максимально компактной сборки можно дополнительно указать переключатель --disable-cgi, чтобы генерировался только бинарный файл CLI.

Есть ещё три переключателя, которые обычно следует указывать при разработке расширений или работе над PHP:

--enable-debug включает режим отладки, который даёт несколько эффектов: компиляция будет выполняться с -g для генерации debug-символов, а также с самым низким уровнем оптимизации -O0. Это сделает PHP значительно медленнее, но сделает отладку инструментами вроде gdb более предсказуемой. Кроме того, режим отладки определяет макрос ZEND_DEBUG, который включает использование assertions и различные вспомогательные средства отладки в движке. В частности, будут сообщаться утечки памяти, а также некорректное использование некоторых структур данных. Включить debug-assertions без отключения оптимизаций можно, используя вместо этого --enable-debug-assertions.

--enable-zts (или --enable-maintainer-zts до PHP 8.0) включает потокобезопасность. Этот переключатель определяет макрос ZTS, который в свою очередь включает весь механизм TSRM (thread-safe resource manager), используемый PHP. Начиная с PHP 7 постоянное включение этого переключателя гораздо менее важно, чем в предыдущих версиях. Важнее всего убедиться, что вы включили весь необходимый шаблонный код. Если вам нужна дополнительная информация о потокобезопасности и управлении глобальной памятью в PHP, прочитайте главу об управлении глобальными переменными

--enable-werror (начиная с PHP 7.4) включает флаг компилятора -Werror, который превращает предупреждения компилятора в ошибки. Включение этого флага гарантирует, что сборка PHP останется без предупреждений. Однако генерируемые предупреждения зависят от используемого компилятора, его версии и опций оптимизации, поэтому некоторые компиляторы могут быть несовместимы с этой опцией.

С другой стороны, не следует использовать опцию --enable-debug, если вы хотите провести замеры производительности своего кода. --enable-zts также может негативно повлиять на производительность во время выполнения.

Обратите внимание, что --enable-debug и --enable-zts изменяют ABI бинарного файла PHP, например, добавляя дополнительные аргументы к функциям. Поэтому разделяемые расширения, скомпилированные в режиме отладки, несовместимы с бинарным файлом PHP, собранным в release-режиме. Аналогично, потокобезопасное расширение (ZTS) несовместимо со сборкой PHP, не поддерживающей потокобезопасность (NTS).

Из-за несовместимости ABI make install (и установка через PECL) размещает разделяемые расширения в разных директориях в зависимости от этих опций:

  • $PREFIX/lib/php/extensions/no-debug-non-zts-API_NO для release-сборок без ZTS

  • $PREFIX/lib/php/extensions/debug-non-zts-API_NO для debug-сборок без ZTS

  • $PREFIX/lib/php/extensions/no-debug-zts-API_NO для release-сборок с ZTS

  • $PREFIX/lib/php/extensions/debug-zts-API_NO для debug-сборок с ZTS

Заглушка API_NO выше относится к ZEND_MODULE_API_NO и представляет собой просто дату вроде 20100525, которая используется для внутреннего версионирования API.

Для большинства целей описанных выше переключателей конфигурации должно быть достаточно, но, конечно, ./configure предоставляет гораздо больше опций, описанных в справке.

Помимо передачи опций в configure, можно также указать ряд переменных окружения. Некоторые из наиболее важных документированы в конце вывода справки configure (./configure --help | tail -25).

Например, вы можете использовать CC, чтобы задать другой компилятор, и CFLAGS, чтобы изменить используемые флаги компиляции:

~/php-src> ./configure --disable-all CC=clang CFLAGS="-O3 -march=native"

В такой конфигурации сборка будет использовать clang (вместо gcc) и очень высокий уровень оптимизации (-O3 -march=native).

Опция, особенно полезная для разработки — -fsanitize, которая позволяет обнаруживать повреждение памяти и неопределённое поведение во время выполнения:

CFLAGS="-fsanitize=address -fsanitize=undefined"

Эти опции надёжно работают только начиная с PHP 7.4 и значительно замедляют сгенерированный бинарный файл PHP.

make и make install

После того как всё настроено, можно использовать make для выполнения непосредственной компиляции:

~/php-src> make -jN    # where N is the number of cores

Основным результатом этой операции будут бинарные файлы PHP для включённых SAPI (по умолчанию sapi/cli/php и sapi/cgi/php-cgi), а также разделяемые расширения в директории modules/.

Теперь вы можете выполнить make install, чтобы установить PHP в /usr/local (по умолчанию) или в любую директорию, указанную с помощью переключателя configure --prefix.

make install делает немногим больше, чем копирует ряд файлов в новое место. Если при конфигурировании вы указали --with-pear, также будет скачан и установлен PEAR. Вот итоговое дерево стандартной сборки PHP:

> tree -L 3 -F ~/myphp

/home/myuser/myphp
|-- bin
|   |-- pear*
|   |-- peardev*
|   |-- pecl*
|   |-- phar -> /home/myuser/myphp/bin/phar.phar*
|   |-- phar.phar*
|   |-- php*
|   |-- php-cgi*
|   |-- php-config*
|   `-- phpize*
|-- etc
|   `-- pear.conf
|-- include
|   `-- php
|       |-- ext/
|       |-- include/
|       |-- main/
|       |-- sapi/
|       |-- TSRM/
|       `-- Zend/
|-- lib
|   `-- php
|       |-- Archive/
|       |-- build/
|       |-- Console/
|       |-- data/
|       |-- doc/
|       |-- OS/
|       |-- PEAR/
|       |-- PEAR5.php
|       |-- pearcmd.php
|       |-- PEAR.php
|       |-- peclcmd.php
|       |-- Structures/
|       |-- System.php
|       |-- test/
|       `-- XML/
`-- php
    `-- man
        `-- man1/

Краткий обзор структуры директорий:

  • bin/ содержит бинарные файлы SAPI (php и php-cgi), а также скрипты phpize и php-config. Здесь же находятся различные скрипты PEAR/PECL.

  • etc/ содержит конфигурацию. Обратите внимание, что директория php.ini по умолчанию находится не здесь.

  • include/php содержит заголовочные файлы, необходимые для сборки дополнительных расширений или встраивания PHP в собственное программное обеспечение.

  • lib/php содержит файлы PEAR. Директория lib/php/build включает файлы, необходимые для сборки расширений, например файл php.m4, содержащий M4-макросы PHP. Если бы мы скомпилировали какие-либо разделяемые расширения, эти файлы находились бы в подкаталоге lib/php/extensions.

  • php/man, как можно догадаться, содержит man-страницы для команды php.

Как уже упоминалось, расположение php.ini по умолчанию — не etc/. Узнать это расположение можно с помощью опции --ini бинарного файла PHP:

~/myphp/bin> ./php --ini
Configuration File (php.ini) Path: /home/myuser/myphp/lib
Loaded Configuration File:         (none)
Scan for additional .ini files in: (none)
Additional .ini files parsed:      (none)

Как видите, директория php.ini по умолчанию — это $PREFIX/lib (libdir), а не $PREFIX/etc (sysconfdir). Расположение php.ini по умолчанию можно изменить с помощью опции configure --with-config-file-path=PATH.

Также обратите внимание, что make install не создаёт ini-файл. Если вы хотите использовать файл php.ini, создать его — ваша ответственность. Например, вы можете скопировать конфигурацию для разработки по умолчанию:

~/myphp/bin> cp ~/php-src/php.ini-development ~/myphp/lib/php.ini
~/myphp/bin> ./php --ini
Configuration File (php.ini) Path: /home/myuser/myphp/lib
Loaded Configuration File:         /home/myuser/myphp/lib/php.ini
Scan for additional .ini files in: (none)
Additional .ini files parsed:      (none)

Помимо бинарных файлов PHP директория bin/ также содержит два важных скрипта: phpize и php-config.

phpize — это эквивалент ./buildconf для расширений. Он копирует различные файлы из lib/php/build и вызывает autoconf/autoheader. Подробнее об этом инструменте вы узнаете в следующем разделе.

php-config предоставляет информацию о конфигурации сборки PHP. Попробуйте:

~/myphp/bin> ./php-config
Usage: ./php-config [OPTION]
Options:
  --prefix            [/home/myuser/myphp]
  --includes          [-I/home/myuser/myphp/include/php -I/home/myuser/myphp/include/php/main -I/home/myuser/myphp/include/php/TSRM -I/home/myuser/myphp/include/php/Zend -I/home/myuser/myphp/include/php/ext -I/home/myuser/myphp/include/php/ext/date/lib]
  --ldflags           [ -L/usr/lib/i386-linux-gnu]
  --libs              [-lcrypt   -lresolv -lcrypt -lrt -lrt -lm -ldl -lnsl  -lxml2 -lxml2 -lxml2 -lcrypt -lxml2 -lxml2 -lxml2 -lcrypt ]
  --extension-dir     [/home/myuser/myphp/lib/php/extensions/debug-zts-20100525]
  --include-dir       [/home/myuser/myphp/include/php]
  --man-dir           [/home/myuser/myphp/php/man]
  --php-binary        [/home/myuser/myphp/bin/php]
  --php-sapis         [ cli cgi]
  --configure-options [--prefix=/home/myuser/myphp --enable-debug --enable-maintainer-zts]
  --version           [5.4.16-dev]
  --vernum            [50416]

Этот скрипт похож на скрипт pkg-config, используемый дистрибутивами Linux. Он вызывается во время процесса сборки расширения для получения информации об опциях компилятора и путях. Вы также можете использовать его, чтобы быстро получить информацию о своей сборке, например опции configure или директорию расширений по умолчанию. Эта информация также предоставляется ./php -i (phpinfo), но php-config предоставляет её в более простой форме (которую легко использовать автоматизированным инструментам).

Запуск набора тестов

Если команда make завершается успешно, она выводит сообщение, побуждающее выполнить make test:

Build complete.
Don't forget to run 'make test'

make test запускает бинарный файл PHP CLI на нашем наборе тестов, который расположен в различных директориях tests/ дерева исходного кода PHP. Поскольку стандартная сборка проверяется на более чем 10000 тестах (меньше для минимальной сборки, больше при включении дополнительных расширений), это может занять несколько минут.

Команда make test внутри вызывает файл run-tests.php с помощью вашего бинарного файла CLI. Для большего контроля рекомендуется вызывать run-tests.php напрямую. Например, это позволит включить параллельный запуск тестов:

~/php-src> sapi/cli/php run-tests.php -jN

Параллелизм тестов доступен только начиная с PHP 7.4. В более ранних версиях PHP параллелизм недоступен, и необходимо дополнительно передать опцию -P:

~/php-src> sapi/cli/php run-tests.php -P

Вместо запуска всего набора тестов можно также ограничиться определёнными директориями, передав их как аргументы в run-tests.php. Например, чтобы протестировать только движок Zend, расширение reflection и функции для массивов:

~/php-src> sapi/cli/php run-tests.php -jN Zend/ ext/reflection/ ext/standard/tests/array/

Это очень полезно, поскольку позволяет быстро запускать только те части набора тестов, которые относятся к вашим изменениям. Например, если вы вносите изменения в язык, вас, вероятно, не интересуют тесты расширений, и вы хотите только убедиться, что движок Zend продолжает работать корректно.

Вы можете выполнить sapi/cli/php run-tests.php --help, чтобы увидеть полный список опций, принимаемых тестовым раннером. Некоторые особенно полезные опции:

  • -c php.ini можно использовать, чтобы указать файл php.ini для использования.

  • -d foo=bar можно использовать, чтобы задать опции ini.

  • -m запускает тесты под valgrind для обнаружения ошибок памяти. Обратите внимание, что это крайне медленно.

  • --asan следует устанавливать при компиляции PHP с -fsanitize=address. Вместе они приблизительно эквивалентны запуску под valgrind, но с гораздо лучшей производительностью.

Вам не нужно явно использовать run-tests.php для передачи опций или ограничения директорий. Вместо этого можно использовать переменную TESTS, чтобы передать дополнительные аргументы через make test. Например, эквивалент предыдущей команды будет таким:

~/php-src> make test TESTS="-jN Zend/ ext/reflection/ ext/standard/tests/array/"

Позже мы подробнее рассмотрим систему run-tests.php, в частности также поговорим о том, как писать собственные тесты и как отлаживать падения тестов. См. отдельную главу о тестах.

Исправление проблем компиляции и make clean

Как вы, возможно, знаете, make выполняет инкрементальную сборку, то есть перекомпилирует не все файлы, а только те файлы .c, которые изменились с момента последнего запуска. Это отличный способ сократить время сборки, но он не всегда работает хорошо: например, если вы изменяете структуру в заголовочном файле, make автоматически не перекомпилирует все файлы .c, использующие этот заголовок, что приводит к неработающей сборке.

Если вы получаете странные ошибки при выполнении make или итоговый бинарный файл не работает (например, если make test приводит к краху до запуска первого теста), попробуйте выполнить make clean. Это удалит все скомпилированные объекты, тем самым заставив следующий вызов make выполнить полную сборку. (Вы можете использовать ccache, чтобы снизить стоимость пересборок.)

Иногда вам также нужно выполнять make clean после изменения опций ./configure. Если вы только включаете дополнительные расширения, инкрементальная сборка должна быть безопасна, но изменение других опций может потребовать полной пересборки.

Другой источник проблем компиляции — изменение файлов config.m4 или других файлов, входящих в систему сборки PHP. Если такой файл изменяется, необходимо повторно выполнить скрипты ./buildconf и ./configure. Если вы вносите изменение сами, вы, вероятно, вспомните о необходимости выполнить команду, но если это происходит в рамках git pull (или другой команды обновления), проблема может быть не так очевидна.

Если вы столкнулись с какими-либо странными проблемами компиляции, которые не решаются make clean, велика вероятность, что выполнение ./buildconf решит проблему. Чтобы не набирать заново предыдущие опции ./configure, вы можете воспользоваться скриптом ./config.nice (который содержит ваш последний вызов ./configure):

~/php-src> make clean
~/php-src> ./buildconf --force
~/php-src> ./config.nice
~/php-src> make -jN

Последний скрипт очистки, который предоставляет PHP — ./vcsclean. Он работает только если вы получили исходный код через git. По сути он сводится к вызову git clean -X -f -d, который удалит все неотслеживаемые файлы и директории, игнорируемые git. Используйте его с осторожностью.