|Summary:||perl should not export -D_FILE_OFFSET_BITS=64|
|Product:||[Fedora] Fedora||Reporter:||Joe Orton <jorton>|
|Component:||perl||Assignee:||Jason Vas Dias <jvdias>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||David Lawrence <dkl>|
|Version:||rawhide||CC:||cturner, mitr, perl-devel, wtogami|
|Fixed In Version:||ALL||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-11-10 19:13:01 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Description Joe Orton 2004-01-12 13:11:56 UTC
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).
Comment 1 Joe Orton 2004-01-13 09:12:03 UTC
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.
Comment 2 Joe Orton 2004-03-12 08:34:35 UTC
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.
Comment 3 Warren Togami 2004-04-22 02:24:05 UTC
Is this still an issue with the latest perl, or perl in FC2?
Comment 4 Joe Orton 2004-04-22 08:00:54 UTC
$ 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
Comment 5 Warren Togami 2005-05-17 23:57:12 UTC
Do we still want to fix this? What possible bad effects might this cause to change it now?
Comment 6 Joe Orton 2005-05-23 12:30:40 UTC
Yes, it still needs to be fixed. It shouldn't cause any undesired side-effects. Fixing it is probably Hard, though.
Comment 7 Warren Togami 2005-08-28 21:26:15 UTC
> 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?
Comment 8 Joe Orton 2005-08-30 08:10:50 UTC
Hard because it means messing with Perl internals. I don't know
Comment 9 Warren Togami 2005-10-18 03:05:39 UTC
Hey Chip, any recommendations for what to do on this?
Comment 10 Jason Vas Dias 2005-11-10 19:13:01 UTC
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.