LINUX.ORG.RU

Опции ./configure для компиляции нового PHP


0

0

Хочу разобраться, как правильно прописывать опции ./configure для компиляции нового PHP. Правильно ли в качестве основы брать опции из phpinfo() работающего на данный момент интерпретатора? Насколько я понимаю, все опции делятся на 2 типа: 1)Пути к чему-либо нужному --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin

2)Использовать ли определенные модули/опции --without-mysql --without-gd --with-imap

С опциями 2 типа все понятно. А как устанавливать опции 1 типа? Я могу указать какие угодно каталоги и make install скопирует все необходимое в них? Или я могу свободно выбирать каталоги для компилируемых файлов, а пути к другим пакетам CentOS менять нельзя? Как в этом разобраться? Может ссылки какие-нибудь посоветуете?

Заранее благодарен за любую помощь



Последнее исправление: mvi (всего исправлений: 1)

>- вместо make install просто скопировал sapi/cli/php в /bin/phpimap/php (не стал запускать make install, так как файлы скопируются поверх старого интерпретатора и будет только новый, а мне нужно сохранить старый)


make install DESTDIR=/tmp/newphp

потом копируете _все_ нужные файлы, а не просто бинарник

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

это похоже на решение моей проблемы, но можно ли разъяснить поподробнее, как и почему это сработает, в частности:

make install DESTDIR=/tmp/newphp
потом копируете _все_ нужные файлы, а не просто бинарник

Не понимаю, чем это отличается от make + копирования. Я так понял, что все в пути уже прописаны на этапе ./configure.

если хотите сохранить и новый и старый, задайте новому новый --prefix

а как работает --prefix? почему именно это позволит новому не конфликтовать со старым?

mvi
() автор топика
Ответ на: комментарий от mvi

не хотите чтобы make install копировал что-то куда-то, используйте DESTDIR чтобы копировать вручную и видеть что куда кладется и что-где будет переписываться

--prefix задает корень для инсталляции и базу путей куда что будет установлено ( хотя можно задавать и --libdir --sysconfdir и т д по отдельности ) разные пути инсталляции - устанавливаются 2 независимые копии, конфликтовать они не должны, если это будет вызов именно интерпретатора

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

если я правильно понял, то --prefix работает как chroot, ограничивая все компоненты chroot каталогом?

mvi
() автор топика
Ответ на: комментарий от Sylvia

некоторые хостинг-провайдеры приводят похожий рецепт (сам пробовал, нормально работает, только не вдумывался почему и как это работает), т.е.
1) сборка ведется не от root, а от рядового юзера в своем каталоге
2) ./configure --prefix=/home/uXXXXX/php \
--with-mysql=/usr/local --enable-ftp --enable-dbase \
--with-gdbm --with-ndbm --with-iconv=/usr/local \
--with-gd=/usr/local --enable-gd-native-ttf=/usr/local \
--with-jpeg-dir=/usr/local --with-png-dir=/usr/local \
--with-freetype-dir=/usr/local --with-ttf \
--with-zlib-dir=/usr --disable-posix \
--enable-force-cgi-redirect --enable-inline-optimization \
--without-pear --disable-debug --with-imap --with-imap-ssl

а дальше видимо --prefix запирает все файлы в каталоге пользователя.
Так может быть и мне от рядового пользователя сборку производить, тогда уж он точно не сможет на главный php повлиять?

mvi
() автор топика
Ответ на: комментарий от mvi

> если я правильно понял, то --prefix работает как chroot, ограничивая все компоненты chroot каталогом?

Нет, он просто указывает путь, относительно которого все это будет проинсталлировано. А вообще — man hier.

Дай виндузятнику CentOS хрустальный... А потом окажется, что вообще ничего не надо было пересобирать, достаточно было кастомного php.ini.

shimon ★★★★★
()
Ответ на: комментарий от shimon

> А потом окажется, что вообще ничего не надо было пересобирать, достаточно было кастомного php.ini.

99,9%

boombick ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.