Bug#636651: mod_perl2 and Perl 5.14 with uselargefiles on 32-bit architectures (was: Early core dump)

[Dominic Hargreaves]

[dropping upstream list back off]

On Sat, Oct 22, 2011 at 09:08:08PM +0300, Niko Tyni wrote:
> 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?

Hi Niko, and pkg-perl,

Since this the only significant blocker now, I'd like to try and get it
wrapped up one way or another. I've built libapache2-mod-perl2 with the
attached patch today, and run request-tracker4 with mod_perl happily on
it, with perl 5.12 and 5.14. If I understand things correctly from the
above, you think this should be okay, for Debian if not for upstream (it
wasn't obvious to me) but wanted additional verification. Since we haven't
had any response to that specific point, either negative or positive, I
think it's probably time to give it a try - it's unlikely to be worse
than not having libapache2-mod-perl2 installable.

Release team has now approved the upload of perl 5.14 to unstable, so
would be good to get this sorted out in the next couple of days.

Cheers,
Dominic.

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 250-lfs-perl-5.14.patch
Type: text/x-diff
Size: 7495 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/attachments/20111112/07a7edaa/attachment-0001.patch>