По сути, мне просто интересно, могу ли я перетащить файл libphp5.so на другой сервер без PHP и иметь функциональность PHP и всех расширений, статически скомпилированных в него. (Скомпилировано из исходников с кучей расширений)
Я попытался использовать инструмент ld для файла so (на моем сервере), но он просто выплюнул кучу неопределенных ссылок. Которые не имеют значения, так как это рабочая установка.
Редактировать:
Теперь я понимаю, что использовал ld
вместо того ldd
. Теперь я получаю список зависимостей. Полагаю, мне понадобятся все эти файлы правильно? Итак, мой вопрос: если я рекурсивно получу все общие объектные файлы и помещу их в те же места на целевом сервере (возможно, через настраиваемый RPM), будет ли PHP работать на новом сервере без формальной установки PHP?
Могу ли я упустить какие-либо скрытые зависимости, которые не обнаруживает ldd?
Библиотека .so - это разделяемая библиотека, в точности противоположная статической библиотеке. Если вы статически компилируете установку PHP, у вас будет один (очень большой) исполняемый файл, который, вероятно, называется «php», но не будет файлов .so.
Я считаю, что невозможно (или, по крайней мере, это очень плохая идея) «статически» скомпилировать файл .so. Причина в том, что вы фактически будете копировать сотни, если не тысячи функций в файл .so, что не только сделает его огромным, но и может вызвать ошибки при загрузке библиотеки. Например, если приложение (например, веб-сервер) загружает стандартную библиотеку C с функцией strcpy () в ней, тогда оно загружает ваш «статический» файл .so, в котором также есть функция strcpy (), может быть конфликтом. Вы можете обойти это, тщательно экспортировав только необходимые символы или используя вместо этого dlopen () в приложении, но в лучшем случае вы получите очень большой файл .so, который тратит много памяти.
Что вы могли сделать, так это использовать ldd
чтобы выбрать все нужные файлы .so, запустить все расширения, а затем поместить их все в ту же папку, что и файл .so. Если вы затем установите LD_LIBRARY_PATH
переменную окружения в этот каталог перед запуском приложения, оно должно получить PHP и все его зависимости из этой папки. Это не дало бы вам волшебного однофайлового подхода, но, по крайней мере, позволило бы вам хранить все в одной папке.