Hide Forgot
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 not reliable. 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 this fixed.
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-5.8.3-13 $ perl -V:ccflags ccflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm'; yup
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.