Bug 113304

Summary: perl should not export -D_FILE_OFFSET_BITS=64
Product: [Fedora] Fedora Reporter: Joe Orton <jorton>
Component: perlAssignee: Jason Vas Dias <jvdias>
Status: CLOSED CURRENTRELEASE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: cturner, mitr, perl-devel, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: ALL Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-11-10 19:13:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 150222    

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 -V:ccflags
-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm';


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.