Stas Bekman wrote:
One other explanation could be type sizes mismatch between perl and apr, but I don't see anything like this happening in here. Though this is something that needs to be checked. Usually this happens if apache and perl are not both build with large_files or w/o. e.g. we have this problem in apr/perlio's seek function. I was passing the value to seek to and the function would convert it to zero. later with help of Nick S.I. from p5p I have learned that the problem was in the type mismatch, perl was passing 64 bit int and apr was accepting 32 bit int, and voila some kind of truncation/alignment was happening.
In any case can you check whether you have both perl and apache built with largefiles or both without? Just check whether you have MP_LARGE_FILES_CONFLICT defined in src/modules/perl/mod_perl.h
Index: src/modules/perl/mod_perl.h =================================================================== RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.h,v retrieving revision 1.60 diff -u -r1.60 mod_perl.h --- src/modules/perl/mod_perl.h 20 Aug 2003 23:20:14 -0000 1.60 +++ src/modules/perl/mod_perl.h 19 Sep 2003 09:11:47 -0000 @@ -43,6 +43,10 @@ #define MP_LARGE_FILES_CONFLICT \ !(MP_LARGE_FILES_ENABLED || MP_LARGE_FILES_DISABLED)
+#ifdef MP_LARGE_FILES_CONFLICT +#error "Large files conflict!" +#endif + #ifdef MP_USE_GTOP #include "modperl_gtop.h" #endif
if it fails to compile you have this conflict.
Yikes! I have a large files conflict!
I specifically built my Perl *with* large files support, believing that Apache2 had it. (And conversely, I've always built Perl *without* LFS when I'm using mp1 because Apache1 doesn't have it.) Is this not the case?
Do I need to do anything special to enable LFS in either Apache2 or mp2? Or should I just rebuild Perl without LFS?
- Steve
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
