You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Niko Tyni <nt...@debian.org> on 2011/10/22 20:08:08 UTC
Re: mod_perl2 and Perl 5.14 with uselargefiles on 32-bit
architectures (was: Early core dump)
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 ntyni@debian.org
Re: Bug#636651: mod_perl2 and Perl 5.14 with uselargefiles on
32-bit architectures
Posted by Dominic Hargreaves <do...@earth.li>.
On Sun, Oct 23, 2011 at 02:10:07PM +0200, Torsten Förtsch wrote:
> On Sunday, 23 October 2011 00:12:13 Marco Walther wrote:
> > As I said above, I checked for the Apache version, but a check for
> > APR version would probably be better.
>
> If you think there is a problem in modperl and you resolved it could you
> please provide a patch against trunk? Chances that it would be applied
> are much higher that way. It would also be much easier to review.
The patch we've applied to mod_perl on Debian is:
<http://patch-tracker.debian.org/patch/series/view/libapache2-mod-perl2/2.0.5-4/250-lfs-perl-5.14.patch>
however I'm not sure if that's suitable for upstream application. I
thought it would be worth getting some visibility of this change,
in any case.
Cheers,
Dominic.
--
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)
Re: mod_perl2 and Perl 5.14 with uselargefiles on 32-bit architectures
Posted by Torsten Förtsch <to...@gmx.net>.
On Sunday, 23 October 2011 00:12:13 Marco Walther wrote:
> As I said above, I checked for the Apache version, but a check for
> APR version would probably be better.
If you think there is a problem in modperl and you resolved it could you
please provide a patch against trunk? Chances that it would be applied
are much higher that way. It would also be much easier to review.
Thanks,
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
Re: mod_perl2 and Perl 5.14 with uselargefiles on 32-bit architectures
Posted by Marco Walther <ma...@oracle.com>.
On 10/22/2011 11:08 AM, 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().
Yes.
> 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=1125476io
I did pretty much the same (the return 0 for apache version > 2.2.20)
for 2.0.6-dev and it seems to work ok.
> 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?
As I said above, I checked for the Apache version, but a check for APR
version would probably be better.
I was running into some other LFS related problems where some CPAN
modules did not use the CFLAGS from the Perl build but picked up the
environment:-(
The symptoms were very strange:-( Bugzilla calls exit() all over the
place and that's supposed to be overridden by mod_perl to do the right
thing. But for me it looked like the real exit() was called instead.
This was caused by Params-Validate-1.00 picking up CFLAGS from the
environment without the LFS from the Perl build:-( Other problematic
modules for me were DateTime-0.70 (similar strange failures) and
Convert-UUlib-1.4 (this was found while looking through my build logs?!)
Have fun,
-- Marco
> Cheers,