Bug#636651: mod_perl2 and Perl 5.14 with uselargefiles on 32-bit architectures (was: Early core dump)
On Sun, Nov 13, 2011 at 02:17:48PM +0200, Niko Tyni wrote: On Sat, Nov 12, 2011 at 09:29:50PM +, Dominic Hargreaves wrote: 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. I assume this is on i386? Yup. 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. Yes, I agree it's definitely worth trying. Many thanks for pushing this. I'm not sure if it's cleaner to patch away all the related functions (strip_lfs() and has_large_files_conflict()) like you do, or just stop calling them. Your approach is probably safer as it makes sure nobody else uses them. You might want to stick in a comment pointing to the Debian bug in the patched versions, though, so that anybody reading through the code in the binary package is aware that we're patching it. Yeah, good point. A note about this on the upstream list would also be appropriate IMO. The discussion there didn't really get far but I think other distributions are hitting this too. (What's Fedora doing BTW? I think they're shipping with 5.14 now.) A quick look at http://download.fedora.redhat.com/pub/fedora/linux/releases/16/Fedora/source/SRPMS/mod_perl-2.0.5-5.fc16.src.rpm suggests that they aren't patching for this issue; and having spun up a FC16 VM, the reason becomes clear; they aren't compiling with -D_FILE_OFFSET_BITS=64. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636651: mod_perl2 and Perl 5.14 with uselargefiles on 32-bit architectures (was: Early core dump)
On Sat, Nov 12, 2011 at 09:29:50PM +, Dominic Hargreaves wrote: 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. I assume this is on i386? 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. Yes, I agree it's definitely worth trying. Many thanks for pushing this. I'm not sure if it's cleaner to patch away all the related functions (strip_lfs() and has_large_files_conflict()) like you do, or just stop calling them. Your approach is probably safer as it makes sure nobody else uses them. You might want to stick in a comment pointing to the Debian bug in the patched versions, though, so that anybody reading through the code in the binary package is aware that we're patching it. A note about this on the upstream list would also be appropriate IMO. The discussion there didn't really get far but I think other distributions are hitting this too. (What's Fedora doing BTW? I think they're shipping with 5.14 now.) -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636651: mod_perl2 and Perl 5.14 with uselargefiles on 32-bit architectures (was: Early core dump)
[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=932879r2=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=932879r2=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
Bug#636651: 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=932879r2=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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
