[EMAIL PROTECTED] wrote:
stas2004/04/01 18:17:46
Modified:ModPerl-Registry/lib/ModPerl RegistryCooker.pm
ModPerl-Registry/t perlrun_extload.t special_blocks.t
ModPerl-Registry/t/cgi-bin perlrun_decl.pm
perlrun_extload.pl perlrun_n
Joe Orton wrote:
On Thu, Apr 01, 2004 at 02:49:56PM -0800, Stas Bekman wrote:
Joe Orton wrote:
I actually can't convince myself that changing APR_HAS_LARGE_FILES to be
0 on APR HEAD when LFS support is *enabled* is the right thing to do; it
just doesn't make sense.
I think the right way to solve
On Thu, Apr 01, 2004 at 02:49:56PM -0800, Stas Bekman wrote:
> Joe Orton wrote:
> >I actually can't convince myself that changing APR_HAS_LARGE_FILES to be
> >0 on APR HEAD when LFS support is *enabled* is the right thing to do; it
> >just doesn't make sense.
> >
> >I think the right way to solve t
Joe Orton wrote:
I actually can't convince myself that changing APR_HAS_LARGE_FILES to be
0 on APR HEAD when LFS support is *enabled* is the right thing to do; it
just doesn't make sense.
I think the right way to solve this is to make mod_perl's
has_large_files_conflict/strip_lfs functions a bit mo
I actually can't convince myself that changing APR_HAS_LARGE_FILES to be
0 on APR HEAD when LFS support is *enabled* is the right thing to do; it
just doesn't make sense.
I think the right way to solve this is to make mod_perl's
has_large_files_conflict/strip_lfs functions a bit more smarter, I'll
Kiki wrote:
OK, I tried 1.99_13 with the same results. The build environment is the
same as for 1.99_12 so I guess the same Bug Report Info applies here too (I
can generate another bug report if you need it though)
No, no, that's fine. Hmm, I don't remember seeing mach reports before. Is that
Mac
Joe Orton wrote:
Joe, regarding your change:
http://marc.theaimsgroup.com/?l=apr-cvs&m=108039307912906&w=2
which seems to completely hose mod_perl 2
Are you sure this is a good step:
+#if APR_HAS_LARGE_FILES
+#define lseek(f,o,w) lseek64(f,o,w)
+#define ftruncate(f,l) ftruncate64(f,l)
+#endif
Joe Orton wrote:
> On Thu, Apr 01, 2004 at 09:09:22AM -0500, Geoffrey Young wrote:
>
>>as an aside, does it make sense to add something about LFS to the output of
>>httpd -V?
>
>
> Oooh, hmmm, dunno. Problem is that all that users probably want to know
> is whether "large" (>2gb) files are sup
> so s/APR_HAS_LARGE_FILES 1/APR_HAS_LARGE_FILES 0/ on apr.h and the
> problem will go away. I'll fix APR.
yup, that seemed to do the trick. verified with both prefork and worker
without --disable-lfs.
as an aside, does it make sense to add something about LFS to the output of
httpd -V?
anyw
> The worker backtrace is not for the thread which actually generated the
> SEGV; using "info threads" should show which one is different, then
> "thread " and backtrace to switch to it in gdb, if you like.
ok, I'll try that.
>
> What is the repro case? Just build everything from HEAD and run t
On Wed, 31 Mar 2004 10:09:01 -0800
Stas Bekman <[EMAIL PROTECTED]> wrote:
BTW, I subscribed to the list, so you needn't reply to my address too :)
> But definitely move first to 1.99_13 because we aren't going to debug on
> 1.99_12 and we need to be on the same page to have a better chance to
>
11 matches
Mail list logo
