Ну и "грабли" вы находите ... :(
=====================
Была замечена грабля - apache не хочет собиратся с PHP и PERL статическими библиотеками. Решения данной проблемы я не нашел :(
=====================
gzip -dc apache_1.3.27.tar.gz | tar xvf -
cd apache_1.3.27
./configure
cd ..
bzip2 -dc php-4.3.1.tar.bz2 | tar xvf -
cd php-4.3.1
rm -f config.cache
./configure\
--with-apache="../apache_1.3.27/" \
--enable-safe-mode \
--enable-magic-quotes \
--disable-short-tags \
...
make && make install
cd ..
cd mod_perl-1.27
/usr/bin/perl Makefile.PL \
APACHE_SRC=../apache_1.3.27/src \
DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 \
APACI_ARGS=' --server-uid=webserv, \
--server-gid=webgrp, \
--enable-module=so, \
--enable-module=most, \
--enable-shared=max, \
--prefix=/usr/local/apache, \
--activate-module=src/modules/php4/libphp4.a, \
--disable-shared=perl, \
--enable-module=perl \
'
make && make test && make install
apache_1.3.27/src/httpd -l
Compiled-in modules:
http_core.c
mod_so.c
mod_perl.c
mod_php4.c
suexec: disabled; invalid wrapper /usr/local/apache/bin/suexec
вот они, родимые, оба статичесике
также присоединяюсь к замечанию по поводу тестирования mod_perl: _таким_ методом тестируется не он, а работа механизма CGI.
по поводу mod_perl'а: неодноратно встречал замечания следующего характера - "если у вас проблемы со стабильностью работы mod_perl, то соберите его статически". Пример - http://bestpractical.com/rt/
Хотя "на поиграться" сойдет и mod_perl через DSO.
Тщательнее надо, тщательнее ... (с)