perl should not export -D_FILE_OFFSET_BITS=64 on i386.
It's not a good idea to start redefining the size of off_t just in
Perl. Most of the rest of the distribution is built with a 32-bit
off_t, so perl bindings for a library which uses a 32-bit off_t are
viz. zlib is compiled with a 32-bit off_t; perl bindings for zlib will
break if any of the API which use off_t are used.
mod_perl: httpd uses a 32-bit off_t throughout: this is not yet
possible to change without breaking the upstream module ABI.
The preferable alternative is to export
-D_LARGEFILE64_SOURCE in Config.pm's ccflags
and "#define Off_t off64_t" instead of "#define Off_t off_t".
(which shouldn't change the module ABI either).
Marked this high severity as I'd really like to see it fixed for FC2.
We can't include the Subversion bindings for Perl without getting
We found a workaround for the Subversion/Perl/off_t problem, but it's
still a workaround for a nasty problem, Perl should really be fixed.
Is this still an issue with the latest perl, or perl in FC2?
$ rpm -q perl
$ perl -V:ccflags
ccflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING
-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
Do we still want to fix this?
What possible bad effects might this cause to change it now?
Yes, it still needs to be fixed. It shouldn't cause any undesired side-effects.
Fixing it is probably Hard, though.
> Yes, it still needs to be fixed. It shouldn't cause any undesired side-effects.
> Fixing it is probably Hard, though.
Why is it hard? It will take more work than simply changing those flags?
Hard because it means messing with Perl internals. I don't know
Hey Chip, any recommendations for what to do on this?
I believe this is no longer a problem - all current kernels fully support
largefiles, and perl largefile support can be turned on / off by the
'%define largefiles 1'
(default 1) in the .spec files for all current perl releases - if I'm wrong,
please let me know and re-open this bug - thanks.