You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by Joe Schaefer <jo...@sunstarsys.com> on 2003/11/13 22:28:42 UTC
[ANN] libapreq2-2.02-dev release candidate #1
Joe Schaefer <jo...@sunstarsys.com> 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
>
> http://httpd.apache.org/~joes/libapreq2-2.02_01-dev.tar.gz
>
> ==================================================
> @section v2_02_dev Changes with libapreq2-2.02-dev
>
> - November 12, 2003 - Perl API [joes]
>
> Fix bogus pool/cookie initializers in Apache::Cookie::set_attr(),
> which caused Apache::Cookie::new to segfault. Bug
> first reported to modperl list by Wolfgang Kubens.
>
>
> Thanks!
Sorry I forgot to CC apreq-dev@ on this announcement.
Can I get a few more +1s for its release? (I take it
Randy's followup on modperl@ constitutes a +1 already).
--
Joe Schaefer
Re: [ANN] libapreq2-2.02-dev release candidate #1
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Markus Wichitill <ma...@gmx.de> writes:
> >> http://httpd.apache.org/~joes/libapreq2-2.02_01-dev.tar.gz
> > Can I get a few more +1s for its release?
>
> On SuSE Linux 9.0 with self-compiled Apache 2.0.48 (Worker), mod_perl
> 1.99_11 and Perl 5.8.2 it compiles and tests fine (I tested params and
> uploads, but not cookies).
Great- thanks!
> Some things that I noticed, though:
>
> 1) make install added a second "LoadModule apreq_module
> modules/mod_apreq.so" line to httpd.conf. I think I removed a few
> spaces from the first line a while ago, but that should probably not
> make a difference.
Interesting.
> 2) $upload->size() is documented without a [TODO] marker, but doesn't
> seem to exist.
Good catch. You're right, it hasn't been implemented yet. I'll try to
correct the docs before final release.
> 3) $apr->parse() returns a non-zero value on GET requests. While
> parse() isn't required for GET requests, in 1.x, it returned zero
> anyway. Hm, I just noticed parse() is gone from the docs, so I guess
> it's obsolete, but if it's still there for 1.x compatibility, it
> should probably return the same.
There's a big difference here between 1.X and 2.X- parse() only refers
to the body now. The query string is parsed immediately (during new()),
so the semantics of the return value for $req->parse() are different. I
believe the current non-zero return value is correct, given this
interpretation.
However, if you're writing a content handler, you'll get much
better performance out of $req->discard_request_body. You can check
$req->status for the parser's final status. It'll still be non-zero
here on a GET, but that shouldn't be so surprising.
> 4) After I had removed $apr->parse() though, in a multipart/form-data
> upload form, $apr->param() wouldn't see the content of parameters that
> came after a big upload parameter anymore. So maybe parse() is just
> missing from the docs after all?
$req->parse is there, but we're not 100% sure what it should "do"
yet- which is why I took it out of the docs for now. We'll have
a much better picture once we see how Apache::Request looks in
a CGI script.
--
Joe Schaefer
Re: [ANN] libapreq2-2.02-dev release candidate #1
Posted by Markus Wichitill <ma...@gmx.de>.
>> http://httpd.apache.org/~joes/libapreq2-2.02_01-dev.tar.gz
> Can I get a few more +1s for its release?
On SuSE Linux 9.0 with self-compiled Apache 2.0.48 (Worker), mod_perl 1.99_11 and Perl 5.8.2 it compiles and tests fine (I tested params and uploads, but not cookies).
Some things that I noticed, though:
1) make install added a second "LoadModule apreq_module modules/mod_apreq.so" line to httpd.conf. I think I removed a few spaces from the first line a while ago, but that should probably not make a difference.
2) $upload->size() is documented without a [TODO] marker, but doesn't seem to exist.
3) $apr->parse() returns a non-zero value on GET requests. While parse() isn't required for GET requests, in 1.x, it returned zero anyway. Hm, I just noticed parse() is gone from the docs, so I guess it's obsolete, but if it's still there for 1.x compatibility, it should probably return the same.
4) After I had removed $apr->parse() though, in a multipart/form-data upload form, $apr->param() wouldn't see the content of parameters that came after a big upload parameter anymore. So maybe parse() is just missing from the docs after all?
Re: [ANN] libapreq2-2.02-dev release candidate #1
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 17 Nov 2003, Steve Hay wrote:
[ .. ]
> I can only assume that I hadn't cleaned out everything
> from the previous libapreq installation properly, because
> I've now rebuilt everything from scratch and
> libapreq-2.02-dev tests OK!
>
> It'll be interesting to see if I run into the same problem
> again when I next try to upgrade libapreq.
That's probably a problem with the way I set up the Win32
build - I'll work on putting in some checks that the proper
libs are being linked against when building something.
--
best regards,
randy
Re: [ANN] libapreq2-2.02-dev release candidate #1
Posted by Steve Hay <st...@uk.radan.com>.
Randy Kobes wrote:
>On Fri, 14 Nov 2003, Steve Hay wrote:
>
>
>
>>Randy Kobes wrote:
>>
>>
>[ .. ]
>
>
>>>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!
>>
>>
>
>Very strange - I'm a bit baffled. It's like saying the
>8.3 filename and the full filename aren't equivalent.
>
>I'll look into this more on the weekend. One thing that
>may be happening - do you have multiple libapreq2-2.02***
>directories at the same level? If so, are
> "cd C:\Temp\LIBAPR~1.02-\glue\perl && nmake test"
>and
> "cd C:\Temp\libapreq2-2.02-dev\glue\perl && nmake test"
>doing 'nmake test' in the same directory? Perhaps the 8.3
>name puts you into another directory .... This won't solve
>the problem, but at least would explain it.
>
They were definitely going into the same directory.
I can only assume that I hadn't cleaned out everything from the previous
libapreq installation properly, because I've now rebuilt everything from
scratch and libapreq-2.02-dev tests OK!
It'll be interesting to see if I run into the same problem again when I
next try to upgrade libapreq.
>
>[ .. ]
>
>
>>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
>>C:/Temp/libapreq2-2.02-dev/glue/perl/t/conf/httpd.conf:
>> 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 mod_perl.so (could be a static build)
>> </IfModule>
>>
>>So I added these lines to my installed Apache conf file:
>>
>> LoadFile C:/apache2/perl5/bin/perl58.dll
>> LoadModule perl_module modules/mod_perl.so
>>
>>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\mod_perl.so"
>> </IfModule>
>>
>>
>
>I think this is the expected behaviour - Apache::Test will
>add modules it finds in the system httpd.conf to its
>generated httpd.conf, and, for this particular test,
>mod_perl is needed. You may not have had to do this with
>libapreq1 because you had already loaded mod_perl in the
>corresponding C:\Apache\conf\httpd.conf.
>
Yes, I think you're right - I do load mod_perl in Apache1's conf file
before testing libapreq1. I'm sure I didn't use to, though. Maybe it
was the switch to Apache::Test that brought about that change. I think
I didn't use to have to do that when we were using Apache::test.
- 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.
Re: [ANN] libapreq2-2.02-dev release candidate #1
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 14 Nov 2003, Steve Hay wrote:
> Randy Kobes wrote:
[ .. ]
> >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!
Very strange - I'm a bit baffled. It's like saying the
8.3 filename and the full filename aren't equivalent.
I'll look into this more on the weekend. One thing that
may be happening - do you have multiple libapreq2-2.02***
directories at the same level? If so, are
"cd C:\Temp\LIBAPR~1.02-\glue\perl && nmake test"
and
"cd C:\Temp\libapreq2-2.02-dev\glue\perl && nmake test"
doing 'nmake test' in the same directory? Perhaps the 8.3
name puts you into another directory .... This won't solve
the problem, but at least would explain it.
[ .. ]
> 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
> C:/Temp/libapreq2-2.02-dev/glue/perl/t/conf/httpd.conf:
> 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 mod_perl.so (could be a static build)
> </IfModule>
>
> So I added these lines to my installed Apache conf file:
>
> LoadFile C:/apache2/perl5/bin/perl58.dll
> LoadModule perl_module modules/mod_perl.so
>
> 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\mod_perl.so"
> </IfModule>
I think this is the expected behaviour - Apache::Test will
add modules it finds in the system httpd.conf to its
generated httpd.conf, and, for this particular test,
mod_perl is needed. You may not have had to do this with
libapreq1 because you had already loaded mod_perl in the
corresponding C:\Apache\conf\httpd.conf.
--
best regards,
randy
Re: [ANN] libapreq2-2.02-dev release candidate #1
Posted by Steve Hay <st...@uk.radan.com>.
Randy Kobes wrote:
>On Fri, 14 Nov 2003, Steve Hay wrote:
>
>
>
>>Joe Schaefer wrote:
>>
>>
>>
>>>Joe Schaefer <jo...@sunstarsys.com> 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
>>>>
>>>> http://httpd.apache.org/~joes/libapreq2-2.02_01-dev.tar.gz
>>>>
>>>>
>>>>
>>>>
>>>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
>directory,
> 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
difference.
>- 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
C:/Temp/libapreq2-2.02-dev/glue/perl/t/conf/httpd.conf:
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 mod_perl.so (could be a static build)
</IfModule>
So I added these lines to my installed Apache conf file:
LoadFile C:/apache2/perl5/bin/perl58.dll
LoadModule perl_module modules/mod_perl.so
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\mod_perl.so"
</IfModule>
- 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.
Re: [ANN] libapreq2-2.02-dev release candidate #1
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
[...]
> - 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.
That'd be my guess, almost. The newer tests will cause a
segfault if an older Cookie.dll is being picked up instead
of the new one (the bug was in Apache::Cookie's XS glue).
libapreq2.dll is unchanged from 2.01-dev.
--
Joe Schaefer
Re: [ANN] libapreq2-2.02-dev release candidate #1
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 14 Nov 2003, Steve Hay wrote:
> Joe Schaefer wrote:
>
> >Joe Schaefer <jo...@sunstarsys.com> 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
> >>
> >> http://httpd.apache.org/~joes/libapreq2-2.02_01-dev.tar.gz
> >>
> >>
> >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:
>
> The C side of things (nmake, nmake mod_apreq, nmake test) is all OK
> here, but there is something a little strange going on with the cookie
> test in the Perl glue.
>
> "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 guess that means that libapreq itself is OK - the problem seems to be
> with the test suite.
>
> 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.
> 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.
A couple of things perhaps to check:
- does the error log report anything useful?
- does reconfiguring things as, from the top-level
directory,
nmake clean
Perl Makefile.PL
nmake
nmake test
nmake perl_glue
nmake perl_test
change anything?
- 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.
--
best regards,
randy
Re: [ANN] libapreq2-2.02-dev release candidate #1
Posted by Steve Hay <st...@uk.radan.com>.
Joe Schaefer wrote:
>Joe Schaefer <jo...@sunstarsys.com> 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
>>
>> http://httpd.apache.org/~joes/libapreq2-2.02_01-dev.tar.gz
>>
>>
>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:
The C side of things (nmake, nmake mod_apreq, nmake test) is all OK
here, but there is something a little strange going on with the cookie
test in the Perl glue.
"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 guess that means that libapreq itself is OK - the problem seems to be
with the test suite.
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.
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!
- Steve
==========
C:\Temp\libapreq2-2.02-dev>nmake perl_test
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
NMAKE /nologo /f C:\Temp\LIBAPR~1.02-\win32\libapreq2.mak
CFG="libapreq2 - Win32 Release" APACHE="C:/Apache2"
APREQ_HOME="C:\Temp\LIBAPR~1.02-"
NMAKE /nologo /f C:\Temp\LIBAPR~1.02-\win32\mod_apreq.mak
CFG="mod_apreq - Win32 Release" APACHE="C:/Apache2"
APREQ_HOME="C:\Temp\LIBAPR~1.02-"
link.exe @C:\DOCUME~1\steveh\LOCALS~1\Temp\nma02968.
Creating library C:\Temp\LIBAPR~1.02-\win32\libs\mod_apreq.lib and
object C:\Temp\LIBAPR~1.02-\win32\libs\mod_apreq.exp
cd C:\Temp\LIBAPR~1.02-\glue\perl
NMAKE /nologo test
C:\apache2\perl5\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST -clean
C:\apache2\perl5\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST
-bugreport -verbose=0
C:\apache2/bin/Apache.exe -d C:/Temp/LIBAPR~1.02-/glue/perl/t -f
C:/Temp/LIBAPR~1.02-/glue/perl/t/conf/httpd.conf -DAPACHE2
-DPERL_USEITHREADS
using Apache/2.0.48 (winnt MPM)
waiting 60 seconds for server to start: .
waiting 60 seconds for server to start: ok (waited 0 secs)
server localhost:8529 started
apreq\big_input....ok
apreq\cookie.......dubious
Test returned status 5 (wstat 1280, 0x500)
apreq\inherit......ok
apreq\request......ok
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
apreq\cookie.t 5 1280 ?? ?? % ??
*** server localhost:8529 shutdown
!!! error running tests (please examine t\logs\error_log)
NMAKE : fatal error U1077: 'C:\apache2\perl5\bin\perl.exe' : return code
'0x1'
Stop.
NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~2\VC98\Bin\NMAKE.EXE' :
return code '0x2'
Stop.
C:\Temp\libapreq2-2.02-dev>cd glue\perl
C:\Temp\libapreq2-2.02-dev\glue\perl>nmake test
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
C:\apache2\perl5\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST -clean
C:\apache2\perl5\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST
-bugreport -verbose=0
C:\apache2/bin/Apache.exe -d C:/Temp/libapreq2-2.02-dev/glue/perl/t -f
C:/Temp/libapreq2-2.02-dev/glue/perl/t/conf/httpd.conf -DAPACHE2
-DPERL_USEITHREADS
using Apache/2.0.48 (winnt MPM)
waiting 60 seconds for server to start: .
waiting 60 seconds for server to start: ok (waited 0 secs)
server localhost:8529 started
apreq\big_input....ok
apreq\cookie.......ok
apreq\inherit......ok
apreq\request......ok
All tests successful.
Files=4, Tests=34, 6 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
*** server localhost:8529 shutdown
C:\Temp\libapreq2-2.02-dev\glue\perl>
==========
------------------------------------------------
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.