Ну и "грабли" вы находите ... :(

=====================
Была замечена грабля - 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.

Тщательнее надо, тщательнее ... (с)