Hiya folks, just wondering what impact (if any) these changes I've been
working on would have on mod_perl and filters implemented using
mod_perl?
The change is simply that after calling ap_pass_brigade() on a brigade,
any subsequent use of that brigade is likely to segfault since the
brigade struc
Randy Kobes wrote:
[...]
Index: lib/Apache/ParseSource.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/ParseSource.pm,v
[ .. ]
- follow => 1,
+ (Apache::Build::WIN32 ? '' :
Randy Kobes wrote:
I've been working at getting the APR::* modules
decoupled from mod_perl.so on Win32, and have run
into a couple of things that I'm not sure about ...
- one is how to automatically generate the .def file (and
also the .exp file on AIX) for the APR module (which
contains the symbol
Randy Kobes wrote:
In the current cvs, there's a couple of things needed to be
done to link APR::* against the APR lib. The problem
existing now (for Win32) is that the APR::* link against
mod_perl.lib, so that mod_perl.so needs always to be
available. We can get around this by removing the linking
Joe Orton wrote:
Hiya folks, just wondering what impact (if any) these changes I've been
working on would have on mod_perl and filters implemented using
mod_perl?
The change is simply that after calling ap_pass_brigade() on a brigade,
any subsequent use of that brigade is likely to segfault since t
On Sat, Jun 19, 2004 at 11:17:28PM +0300, Stas Bekman wrote:
> Joe Orton wrote:
> >Hiya folks, just wondering what impact (if any) these changes I've been
> >working on would have on mod_perl and filters implemented using
> >mod_perl?
> >
> >The change is simply that after calling ap_pass_brigade()
Joe Orton wrote:
On Sat, Jun 19, 2004 at 11:17:28PM +0300, Stas Bekman wrote:
Joe Orton wrote:
Hiya folks, just wondering what impact (if any) these changes I've been
working on would have on mod_perl and filters implemented using
mod_perl?
The change is simply that after calling ap_pass_brigade()