On Wed, Sep 28, 2011 at 02:22:49PM -0700, Marco Walther wrote: > OK, I think I found one problem. The following two defines don't > make it from the Perl make to the CCFLAGS for the mod_perl:-( > `-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' (They are automatically > added by the Configure for perl and listed in the perl -V output > below). > > That causes the my_perl structure to be of different sizes/offsets > between perl and mod_perl. That works by accident with Perl 5.10.1 > and finally breaks with 5.14.[12]
We're running into this on Debian 32-bit architectures too (http://bugs.debian.org/636651 [cc'd]), and the issue is one of the blockers for our transition to Perl 5.14. > Unfortunately even trying to run > /opt/kenai/bin/perl Makefile.PL DEFINE='-D_LARGEFILE_SOURCE > -D_FILE_OFFSET_BITS=64' > is not enough:-( The defines still do not make it to the > src/modules/perl/Makefile:-( But after changing that Makefile by > hand and rebuilding, things seem to be working fine. These cpp flags are stripped by lib/Apache2/Build.pm, see has_large_files_conflict() and strip_lfs(). The mod_perl2 2.0.5 test suite works for me with Perl 5.14 if I hardwire has_large_files_conflict() to return 0 and apply r1125476 from 2.0.6-dev: http://svn.apache.org/viewvc/perl/modperl/trunk/src/modules/perl/modperl_svptr_table.c?r1=932879&r2=1125476 The elaborate comments about large file issues in lib/Apache2/Build.pm around strip_lfs() seem to be partly outdated; selectively quoting: # on Unix systems where by default off_t is a "long", a 32-bit integer, # there are two different ways to get "large file" support, i.e. the # ability to manipulate files bigger than 2Gb: # # 1) you compile using -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64. [...] # 2) you compile using -D_LARGEFILE64_SOURCE [...] # The problem that mod_perl has to work around is when you take a # package built with approach (1), i.e. Perl, and any package which was # *not* built with (1), i.e. APR, and want to interface between # them. [1] [...] # Perl built with -Duselargefiles uses approach (1). # # APR HEAD uses (2) by default. [...] # [1]: In some cases, it may be OK to interface between packages which # use (1) and packages which use (2). APR HEAD is currently not such a # case, since the size of apr_ino_t is still changing when # _FILE_OFFSET_BITS is defined. The last paragraph dates back to 2004, and the apr changelogs read: > Changes for APR 1.2.12 > *) Define apr_ino_t in such a way that it doesn't change definition > based on the library consumer's -D'efines to the filesystem. > [Lucian Adrian Grijincu <lucian.grijincu gmail.com>] > Changes for APR 1.4.3 > *) configure: Make definition of apr_ino_t independent of > _FILE_OFFSET_BITS even on platforms where ino_t is 'unsigned int'. > [Stefan Fritsch] To summarize, it looks like Apache2::Build::strip_lfs() breaks with Perl 5.14 with -Duselargefiles on 32-bit architectures, and is not necessary since at least apr 1.4.3, possibly earlier. I'd like input on whether we should expect further pitfalls if we build mod_perl2 with -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 on Debian, i.e. stop stripping those flags in Apache2::Build. Obviously, a more portable solution is needed for mod_perl 2.0.6. Perhaps an explicit probe for sizeof(apr_ino_t) with different _FILE_OFFSET_BITS definitions? Cheers, -- Niko Tyni nt...@debian.org