httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Hay <>
Subject Re: [ANN] libapreq2-2.02-dev release candidate #1
Date Fri, 14 Nov 2003 17:21:19 GMT
Randy Kobes wrote:

>On Fri, 14 Nov 2003, Steve Hay wrote:
>>Joe Schaefer wrote:
>>>Joe Schaefer <> writes:
>>>>2.02-dev will be a maintenance release to fix
>>>>the reported segfaults with Apache::Cookie::new().
>>>>Please give this candidate a try at
>>>Can I get a few more +1s for its release? (I take it
>>>Randy's followup on modperl@ constitutes a +1 already).
>>WinXP / MSVC++ 6.0 / Perl 5.8.2 / Apache 2.0.48 / mod_perl 1.99_11:
>>"nmake perl_glue" runs OK, but when I run "nmake perl_test" I find that
>>the cookie test fails with a nasty popup Application Error (Access
>>Violation).  I can't look into why right now because I've got release
>>builds of everything running :(
>>The weird thing is that if I cd into glue/perl and run "nmake test"
>>instead then all the tests pass OK.
>>I've copied some console output of what is going on below.
>>The only strange thing that strikes me at first is that
>>"nmake perl_test" is using a munged "8.3" filename for the
>>directory where I have unpacked the libapreq tarball
>>(C:/Temp/LIBAPR~1.02-), whereas "nmake test" uses the full
>>directory name (C:/Temp/libapreq2-2.02-dev).  However, the
>>previous version that I tested (2.01_03-dev) did the same
>>in that regard and passed all tests OK, so that's unlikely
>>to be the cause.
>I hope it isn't ... The use of the 8.3 filename was
>deliberate, to help cope with possible directories with
>spaces in their names.
I generally prefer to quote directories/files that might have spaces in 
them.  I hate the old 8.3 filenames.

>>Perhaps it would be easier just to remove the "perl_*" targets from the
>>top-level Makefile?  If I'd just cd'd into glue\perl and done the usual
>>"perl Makefile.PL; nmake; nmake test; nmake install" from there then I'd
>>never even have noticed any problem!
>That is weird ... For one thing,
>     nmake perl_test
>just does, as you found,
>[ ... ]
>>        cd C:\Temp\LIBAPR~1.02-\glue\perl
>>        NMAKE /nologo test
>so it does a cd into glue/perl and nmakes test from there.
That snippet above is interesting - I hadn't noticed before that it uses 
the 8.3 name to cd into.  (I used the full name when I cd'd into that 
directory.)  Just for laughs I tried using the 8.3 name to cd into, and 
low-and-behold it does fail!

In case you've lost the plot at this point, I now have:

"nmake perl_test" fails
"cd C:\Temp\LIBAPR~1.02-\glue\perl && nmake test" fails
"cd C:\Temp\libapreq2-2.02-dev\glue\perl && nmake test" works!

>A couple of things perhaps to check:
>- does the error log report anything useful?
No errors or warnings.  The only output is a subset of what the 
successful test run produces.

>- does reconfiguring things as, from the top-level
>     nmake clean
>     Perl Makefile.PL
>     nmake
>     nmake test
>     nmake perl_glue
>     nmake perl_test
>change anything?
No.  Even rebuilding it from a fresh unpack of the archive makes no 

>- have you installed a previous version of libarpeq2, and
>perhaps some parts of that are being picked up? This has
>gotten me before, and if so, I'll have to add in some checks
>that the proper libs are being used.
I did have libapreq2-2.01_03-dev installed, but now I've removed it and 
rebuilt this version of libapreq2 from a fresh unpack of the archive and 
still get the same result.

(I think I correctly removed everything from the Apache2 and Perl5 
installation directories, but without rebuilding Apache & Perl it's hard 
to be sure I've got absolutely everything.  But I have _definitely_ 
removed the old Cookie.dll.)

I just thought of one other weird thing that I've done.  I don't know if 
it is relevant or not, but I don't recall having to do it with 
libapreq1.  I had to edit the httpd.conf file in my Apache installation 
directory (C:\apache2) to load mod_perl.  Initially "nmake perl_test" 
just bombed out straight away with:

    Syntax error on line 185 of 
    Invalid command 'PerlResponseHandler', perhaps mis-spelled or 
defined by a module not included in the server configuration

The  t/conf/httpd.conf file that it wrote contained this:

    <IfModule !mod_perl.c>
        #unable to locate (could be a static build)

So I added these lines to my installed Apache conf file:

    LoadFile C:/apache2/perl5/bin/perl58.dll
    LoadModule perl_module modules/

and tried again.  This time it worked, and the t/conf/httpd.conf file 
contained this:

    <IfModule !mod_perl.c>
        LoadFile "C:\apache2\perl5\bin\perl58.dll"
    LoadModule perl_module "\Apache2\modules\"

- Steve

Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential
and intended for the addressee(s) only.  If you have received this message in error or there
are any problems, please notify the sender immediately.  The unauthorized use, disclosure,
copying or alteration of this message is strictly forbidden.  Note that any views or opinions
presented in this email are solely those of the author and do not necessarily represent those
of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached
files for viruses: Radan Computational will accept no liability for any damage caused by any
virus transmitted by this email.

View raw message