httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Kobes <ra...@theoryx5.uwinnipeg.ca>
Subject Re: [ANN] libapreq2-2.02-dev release candidate #1
Date Fri, 14 Nov 2003 16:00:53 GMT
On Fri, 14 Nov 2003, Steve Hay wrote:

> Joe Schaefer wrote:
>
> >Joe Schaefer <joe+gmane@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

Mime
View raw message