httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gavin Carr <>
Subject Re: Apache2 / mod_perl1 confusion
Date Mon, 24 Jan 2005 06:08:35 GMT
On Fri, Jan 21, 2005 at 09:26:53AM -0500, Geoffrey Young wrote:
> > I'm trying to test a C module against both apache2 and apache1. apache1
> > is working beautifully, but when I attempt to reconfigure for apache2
> > (stock FC1), A::T (1.20) keeps complaining about finding mod_perl 1. I'm
> > doing:
> > 
> >   ./TEST -clean
> >   ./TEST -apxs /usr/sbin/apxs -conf
> when I run tests against both apache 1 and apache 2 I generally 'make
> realclean' and then re- "perl Makefile.PL -apxs..." and it works just fine.
> if you look in t/TEST you'll probably see your old -apxs path in there.
> well, that is, if you specified -apxs when building your Makefile :)

Since this is a C module I'm actually just using a static TEST like this:

  use strict;
  use warnings FATAL => 'all';
  use Apache::TestRunPerl;

straight out of one of the A::T tutorials.

> > With -trace=debug on, I'm getting:
> > 
> > <lots snipped>
> > [  debug] using httpd.conf inherited ServerRoot to resolve modules/
> > [  debug] modules/ successfully resolved to existing file /etc/httpd/modules/
> is that the right mod_perl location for your Apache 2 install?

Yep, that's the right one. The 1.27 one is a custom apache in /opt in this 

> things to check here are that t/conf/ is removed after
> you run t/TEST -clean and what it contains after you run t/TEST -conf.

After -clean the only thing left is my, so that looks good.

> also, try nuking ~/.apache-test after t/TEST -clean and exporting
> APACHE_TEST_NO_STICKY_PREFERENCES=1 before you try again.  part of the
> reason why I coded APACHE_TEST_NO_STICKY_PREFERENCES was because sticky
> preferences tend to get jumbled up when switching between versions (which I
> do a lot :)

No change with APACHE_TEST_NO_STICKY_PREFERENCES=1, and I don't have a
~/.apache-test at all. Nothing actually ends up in t/conf after the -conf
run either - it looks like it's just bailing out.

Any further suggestions of where to look? Might be perl debugger time ...


View raw message