On Dec 11, 2007 9:24 PM, Gunnar Wolf <[EMAIL PROTECTED]> wrote:
> This bug should be closed, if no further answers indicate otherwise -
> mod_perl1 and mod_perl2 are completely different beasts, and expecting
> one behaviour in the other... Just leads to pain ;-)
Since there was no reply in 15 da
-0.5
I would actually like to see builds prepared against MSVCRT80, which is
available in the Vista SDK's bundled free compiler, rather than having
users need to download the SDK + VS Express Edition + configure the one
to find and work with the other (a royal pain). As long as the latest
SDKs ar
Issac Goldstand wrote:
-0.5
I would actually like to see builds prepared against MSVCRT80, which is
available in the Vista SDK's bundled free compiler, rather than having
users need to download the SDK + VS Express Edition + configure the one
to find and work with the other (a royal pain). As l
William A. Rowe, Jr. wrote:
> Issac Goldstand wrote:
>> -0.5
>>
>> I would actually like to see builds prepared against MSVCRT80, which is
>> available in the Vista SDK's bundled free compiler, rather than having
>> users need to download the SDK + VS Express Edition + configure the one
>> to find
I am using mp2bug format for the message. Hope, that's ok!
=
-8<-- Start Bug Report 8<--
1. Problem Description:
I have just upgraded to apache2/modperl2 (bug report with specific
version info is below) and I am getting the str
mod_perl re-defines "perl_free" as "free" in modperl_perl_includes.h:69.
This causes an attempt to use the native Windows free() function to release
memory
which should be released by the perl_free() function located in PerlXXX.dll.
The specific call is in modperl_perl.c:186, function modperl_p
On Sat, 29 Dec 2007, Tom Donovan wrote:
mod_perl re-defines "perl_free" as "free" in modperl_perl_includes.h:69.
This causes an attempt to use the native Windows free() function to release
memory
which should be released by the perl_free() function located in PerlXXX.dll.
The specific call i
