Как заставить скомпилированный php работать с apache?

Я скомпилировал php 7.4 для сервера centos 7. У меня также установлен apache 2.4.

Проблема в том, что я понятия не имею, что делать дальше, чтобы все заработало. Раньше у меня было 2 сайта, работающих с официальным пакетом, поэтому конфигурация должна быть в порядке - единственное, что было изменено, это php - полностью. Зачем мне этот скомпилированный php и почему мне не нравится пакет? Это потому, что мне нужна поддержка ZTS для php, которой нет в предварительно скомпилированной версии, и она необходима для параллельной поддержки (многопоточность)

В Windows вся эта компиляция php и его работа была шуткой по сравнению с этим (это было похоже на 1 день с 0 знаниями). Я просто настроил компилятор, скомпилировал, заменил папку php на веб-сервере, и он работал отлично, и все тесты на сайтах также проходили.

С другой стороны, в centos я скомпилировал php и некоторые расширения + дополнительные пакеты, чтобы он работал. Когда я проверяю модули с php -m, все они хорошо выглядят. Единственная проблема в том, что веб-сервер больше не загружает сайты. И вот уже 4-й день мучаюсь - всегда возникают проблемы нового типа.

После компиляции php я заменил двоичный файл в двоичном файле PHP CLI. На самом деле я понятия не имею, правильно это делать или нет, потому что я не могу найти никакой информации об этой части, потому что большинство описаний заканчивается там, где вы запускаете команду make install или делаете немного дополнительных.

Так что мне нужно руководство от кого-то, кто может объяснить мне, что нужно делать и почему это нужно делать.

В двоичном файле также скомпилирован php-fpm, но я не знаю, влияет ли он на него.

Я также не знаю, как отладить эту ситуацию. Я могу связаться с сервером и увидеть страницу тестирования apache по умолчанию, поэтому, как и ожидалось, она немного не изменилась и работает.

Итак, я хотел бы знать, это какая-то подсказка о том, как это понять, или какое-то объяснение того, какие файлы следует размещать, где и почему?

Спасибо!

Обновление после предложений:

Я повторил весь процесс снова - создал новый том из моментального снимка, который я сделал до того, как начал работать над этим, и начал заново с нуля. Сегодняшний прогресс таков, что после этого не загружались даже модули - zend_opcache и mongodb. Теперь после запуска sudo make install cmd там четко написано, куда ставить модули: /usr/local/php7/lib/php/extensions/no-debug-zts-20190902/ и в описании, которое я нашел, также указано, где изменить файл ini, чтобы он работал: https://shaunfreeman.name/blog/compiling-php-7-on-centos

sudo vim /usr/local/php7/etc/conf.d/modules.ini 

Но это больше не работает, как раньше. Также есть файл php.ini, который предлагается скопировать:

sudo cp -v ./php.ini-production /usr/local/php7/lib/php.ini

Но изменение этого файла php.ini для динамической загрузки расширений также ничего не делает, поэтому я предполагаю, что php, который должен использовать этот файл ini, вообще не видит файл. Итак, я проверил whereis php и он говорит: php: /usr/share/php /usr/local/php7/bin/php

Второй - то, что я вложил в $PATH переменная, но я думаю, что порядок загрузки заключается в загрузке первого. Он был создан при первой установке make, и этот php-файл не меняется при повторном запуске. Может, это вообще не при чем.

Затем у меня возникла еще одна проблема с httpd, когда я запустил httpd -V cmd:

AH00526: Syntax error on line 216 of /etc/httpd/conf.d/ssl.conf:
SuexecUserGroup configured, but suEXEC is disabled: Invalid owner or file mode for /usr/sbin/suexec

у которого было разрешение 510 с парой root: apache user: group. Изменение на 0750 решило эту проблему. Я также не знаю, реализовано ли это - я думаю, что на этот раз так и должно быть, потому что в описании, которое я нашел о suexec, говорится, что он запускает php-cgi. Но это не помогло в общей ситуации.

Затем я проверил модули httpd, у меня был этот модуль в /etc/httpd/modules/ папка: mod_proxy_fcgi.so только, это не означает, что он запускает php с этим, но я могу предположить, не проверяя файл - я должен подтвердить это из файла конфигурации tho.

В папке conf.d есть файл: php.conf.rpmsave, где сказано:

    # Proxy declaration
<Proxy "unix:/var/run/php-fpm/default.sock|fcgi://php-fpm">
        # we must declare a parameter in here (doesn't matter which) or it'll not register the proxy ahead of time
        ProxySet disablereuse=off
</Proxy>

# Redirect to the proxy
<FilesMatch \.php$>
        SetHandler proxy:fcgi://php-fpm
</FilesMatch>

Я не уверен, имеет ли это значение здесь, потому что это может быть только сохраненный файл конфигурации для предыдущей версии php диспетчера пакетов. Также, если я скажу: sudo find / -name php.conf или sudo find / -name *hp.con*, то я возвращаю только этот файл, так что похоже, что скомпилированная версия не сгенерировала файл конфигурации для apache - возможно, в этом и нет необходимости, но, возможно, это проблема. Переименование его с помощью mv в php.conf фактически изменяет ответ по умолчанию с порта 80 с причудливого Testing 123 .. на 503 Service Unavailable. Это может быть связано с тем, что в прошлый раз, когда я компилировал php, я исключил php-fpm, поэтому теперь я собираюсь перекомпилировать его еще раз. Перезапуск сервисов httpd и php-fpm после того, как это было сделано, не помог в ситуации.

Из того, что я вижу, в системе может быть несколько версий файлов сценариев php, что довольно логично, и версии cgi - fcgi, fpm и cli также являются разными сценариями.

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

Также команда php не распознается после того, как я установил скомпилированные версии с make install cmd каждый раз. Возможно, это то, о чем должен позаботиться установщик, а может и нет, в конце концов я поместил скомпилированную двоичную папку в переменную $ PATH, а также добавил ее в сценарий .sh в папке profile.d