[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)
Description: Don't strip LFS CFLAGS any more >From Niko's message <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636651#34>: "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." Bug-Debian: http://bugs.debian.org/636651 diff --git a/lib/Apache2/Build.pm b/lib/Apache2/Build.pm index 97e4089..5e60f8f 100644 --- a/lib/Apache2/Build.pm +++ b/lib/Apache2/Build.pm @@ -598,7 +598,7 @@ sub cmp_tuples { sub perl_ccopts { my $self = shift; - my $cflags = $self->strip_lfs(" $Config{ccflags} "); + my $cflags = " $Config{ccflags} "; my $fixup = \&{"ccopts_$^O"}; if (defined &$fixup) { @@ -2077,94 +2077,6 @@ sub inc { "@includes"; } -### Picking the right LFS support flags for mod_perl, by Joe Orton ### -# -# 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. This -# makes sys/types.h expose off_t as a "long long", a 64-bit integer, and -# changes the size of a few other types too. The C library headers -# automatically arrange to expose a correct implementation of functions -# like lseek() which take off_t parameters. -# -# 2) you compile using -D_LARGEFILE64_SOURCE, and use what is called the -# "transitional" interface. This means that the system headers expose a -# new type, "off64_t", which is a long long, but the size of off_t is not -# changed. A bunch of new functions like lseek64() are exposed by the C -# library headers, which take off64_t parameters in place of off_t. -# -# Perl built with -Duselargefiles uses approach (1). -# -# APR HEAD uses (2) by default. APR 0.9 does not by default use either -# approach, but random users can take a httpd-2.0.49 tarball, and do: -# -# export CPPFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" -# ./configure -# -# to build a copy of apr/httpd which uses approach (1), though this -# isn't really a supported configuration. -# -# 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] -# -# So what you want to know is whether APR was built using approach (1) -# or not. APR_HAS_LARGE_FILES in HEAD just tells you whether APR was -# built using approach (2) or not, which isn't useful in solving this -# problem. -# -# [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. -# -# If you want to see how this matters, get some httpd function to do at -# the very beginning of main(): -# -# printf("sizeof(request_rec) = %lu, sizeof(apr_finfo_t) = %ul", -# sizeof(request_rec), sizeof(apr_finfo_t)); -# -# and then put the same printf in mod_perl somewhere, and see the -# differences. This is why it is a really terribly silly idea to ever -# use approach (1) in anything other than an entirely self-contained -# application. -# -# there is no conflict if both libraries either have or don't have -# large files support enabled -sub has_large_files_conflict { - my $self = shift; - - my $apxs_flags = join $self->apxs_extra_cflags, $self->apxs_extra_cppflags; - my $apr_lfs64 = $apxs_flags =~ /-D_FILE_OFFSET_BITS=64/; - my $perl_lfs64 = $Config{ccflags} =~ /-D_FILE_OFFSET_BITS=64/; - - # XXX: we don't really deal with the case where APR was built with - # -D_FILE_OFFSET_BITS=64 but perl wasn't, since currently we strip - # only perl's ccflags, not apr's flags. the reason we don't deal - # with it is that we didn't have such a case yet, but may need to - # deal with it later - - return $perl_lfs64 ^ $apr_lfs64; -} - -# if perl is built with uselargefiles, but apr not, the build won't -# work together as it uses two binary incompatible libraries, so -# reduce the functionality to the greatest common denominator (C code -# will have to make sure to prevent any operations that may rely on -# effects created by uselargefiles, e.g. Off_t=8 instead of Off_t=4) -sub strip_lfs { - my ($self, $cflags) = @_; - return $cflags unless $self->has_large_files_conflict(); - - my $lf = $Config{ccflags_uselargefiles} - || '-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'; - $cflags =~ s/$lf//; - $cflags; -} - sub define { my $self = shift; diff --git a/xs/APR/PerlIO/Makefile.PL b/xs/APR/PerlIO/Makefile.PL index 4a8f60d..0c9f994 100644 --- a/xs/APR/PerlIO/Makefile.PL +++ b/xs/APR/PerlIO/Makefile.PL @@ -8,23 +8,6 @@ my $build = Apache2::Build->build_config(); my $ccopts = $build->ccopts; -# when uselargefiles is on, -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -# are needed to get the right 'Off_t', without which perlio compiled -# with Off_t as 'long long int', doesn't quite work with apr_perlio.c -# compiled with Off_t as 'long int' -# -# On the other handl if apr is built without large files support, we -# have binary compatibility problems, if we try to build mod_perl with -# -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -# -# XXX: it seems that enabling these flags only for apr_perlio/PerlIO -# seems to do the trick -if ($build->has_large_files_conflict) { - $ccopts .= $Config{uselargefiles} - ? ' ' . $Config{ccflags_uselargefiles} - : ''; -} - ModPerl::BuildMM::WriteMakefile( NAME => 'APR::PerlIO', VERSION_FROM => 'PerlIO.pm',
