Russian Apache Switch to English
Switch to Russian koi8-r
windows=1251
cp-866
iso8859-5
Russian Apache Как это работает Рекоммендации Где взять Как установить Как настроить Статус и поддержка
Краткий обзор FAQ Список рассылки Благодарности Поиск по серверу Powered by Russian Apache
Russian Apache mailing list archive (apache-rus@lists.lexa.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [apache-talk] Strannie yavleniya s Apache+PHP



In <Pine.LNX.4.10.9903062306510.31466-100000@xxxxxxxxxxxxxxxxx> Stanislav Malyshev a.k.a Frodo (frodo@xxxxxxxxxxxx) wrote:
SF> Я тут пытаюсь построить RPM-ы для Апача, и встретился со странными
SF> проблемами. Может быть, кто-то из знакомых с внутренностями Апача и вообще
SF> более умудренный опытом мне подскажет? А то я прямо не знаю что и
SF> делать...

Думать. Головой.

SF> Итак, ситуация:

SF> Есть Russian Apache, последней модели, и есть PHP, 3.0.7. При компиляции
SF> Apache, установке и последующему построению PHP через apxs - PHP не
SF> работает, Apache валится в core при запуске. При построении PHP через
SF> shared-module с установкой внуть Apache - работает. При повторном
SF> построении через apxs - работает тоже. Разница в двух последних случаях -
SF> вроде только в том, что в последнем все библиотеки, нужные mod_php,
SF> прилинковываются и к Apache тоже. Зачем это ему надо - для меня загадка.
SF> Причем при выключении php из Apache tree (путем переконфигурации без
SF> --activate-module и --enable-shared) падение в core возобновляется.
SF> При компиляции всего дерева с модулем и потом сборке httpd руками без
SF> лишних (из PHP) библиотек - падает тоже. Причем дело касается только
SF> динамических библиотек, статические (.a) можно выкидывать как угодно.

Естественно. Дело в том, что этот вариант (когда динамические библиотеки
взлетают автоматом при попытке "руками" загрузить DSO) -- весьма тяжел для
загрузчика. В glibc 2.0.7 (из RedHat'а 5.[12] или KSI-Linux'а 2.0) оно
работает, в glibc 2.1 (по слухам; я не камикадзе -- ставит на рабочую машину
ЭТО; может glibc 2.1.1 или 2.1.2 и поставлю -- когда они жуков
повыловят) -- тоже, но как обстоит дело в beta'х -- не знаю. Знаю только, что
этот загрузчик в glibc 2.1 они переписали (по отношению к 2.0) процентов
этак на 70 (поддержка нескольких версий каждой функции в одной
библиотеке -- штука нетривиальная).

SF> PHP, во всех случаях, строится с --with-mod-charset. Система - Linux
SF> 2.2.2, RH 5.1 плюс всякие апгрейды, libc-2.0.109.so, pgcc-2.91.57.
                                        ^^^^^^^^^^^^^^^
Мдаа. А обязательно искать приключений на свою задницу ? Совместимость
glibc 2.1 и glibc 2.0 -- теория. На практике наблюдаются примерно вышеописанные
эффекты. Или ты весь RH 5.1 перекомпилировал ? Я уж не говорю про использование
весьма древней beta-версии давно (месяц назад :-) вышедшей библиотеки.

SF> Есть какие-нибудь идеи, почему это так происходит и зачем Апачу чужие
SF> библиотеки?

Затем что возникают какие-то глюки в загрузчике. Говорят в release glibc 2.1
оно поправлено. Пока не проверял. В любом случае это -- не проблемы Apache'а
и равным образом не проблемы моих RPM'ов :-)) Они рассчитаны на RedHat, а не
"сборную солянку".

SF> Кстати, еще вопрос - судя по исходникам, Апач проходит весь конфиг
SF> (включая загрузку shared libs) дважды, в main и в standalone_main. Зачем
SF> это ему?

Дык это. Традиция :-) Оно AFAIK еще с NCSA HTTP тянется...




=============================================================================
=               Apache-Talk@xxxxxxxxxxxxx mailing list                      =
Mail "unsubscribe apache-talk" to majordomo@xxxxxxxxxxxxx if you want to quit.
=       Archive avaliable at http://www.lexa.ru/apache-talk                 =






Спонсоры сайта:

[ Russian Apache ] [ Как это работает ] [ Рекомендации ] [ Где взять ] [ Как установить ] [ Как настроить ] [ Статус и поддержка ] [ Краткий обзор ] [ FAQ ] [ Список рассылки ] [ Благодарности ] [ Поиск по серверу ] [ Powered by Russian Apache ] [ Apache-talk archive ]

"Russian Apache" includes software developed by the Apache Group for use in the Apache HTTP server project (http://www.apache.org/) See Apache LICENSE.
Copyright (C) 1995-2001 The Apache Group. All rights reserved.
Copyright (C) 1996 Dm. Kryukov; Copyright (C) 1997-2009 Alex Tutubalin. Design (C) 1998 Max Smolev.