httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Issac Goldstand <>
Subject Re: [RELEASE CANDIDATE] libapreq2 2.09-RC2
Date Fri, 10 Nov 2006 10:45:25 GMT

Philip M. Gollucci wrote:
> Issac Goldstand wrote:
>> Following up on the FAIL report for win32:
> Can you post your "configuration" steps -- I'm the wrong person to ask,
> but someone else might know.  I see Steve H. got passing results.

Just perl Makefile.PL, nmake, nmake test

> Which CGI tests fail ?

Erm, my win32 build computer fizzled a bit last night, but I'll try to
remember to post this on Sunday.  I've already seen the same tests
failing on a separate PC with a separate build environment (at work -
yesterday's build were on my home office PC); I saw it when I was
originally writing the interactive-cgi module (but never found time to
chase them down)

>> The new Apache-Test-1.29-RC2 runs the test suite for 2.08 just fine
>> (against mod_perl-2.0.3-RC2).  However, here the test suite can't load
>> mod_perl (also mod_perl-2.0.3-RC2) into the server properly:
> The dection of mod_perl has changed 0 between 1.27->1.29 much less
> 1.29-rc1 and 1.29-rc2
>> CGI passes most tests (it fails 7; libapreq-2.08 also fails the same
>> ones lately.  That's a separate issue for a separate thread, though),
>> it's just the mod_perl ones that seem to fail.
> Didn't you just contradict yourself ?  I'm probably reading that wrong

I don't think so - the CGI (t/apreq/cgi.t) test runs as a normal CGI, so
IIRC doesn't go through mod_perl...

>> Deeper probing (t/conf/httpd.conf) shows that:
>> <IfModule !mod_perl.c>
>>     #unable to locate (could be a static build)
>> </IfModule>
> Yes that would be the problem. (does Apache-Test have the correct path
> to apxs and is it actually functional?)

I believe so; the same Apache-Test detects the same mod_perl just fine
on the 2.08 tarball - it's really quite odd...  Sunday I'll see if I can
reproduce this at work.

>> Giving a path via t/TEST -libmodperl didn't help
> Unfortunately, httpd-apreq unlike mod_perl does not yet handle this flag.
>> Fixing the path to mod_perl manually in t/conf/httpd.conf did fix it
>> (and all tests but the same 7 from CGI passed).
> D'oh!

View raw message