Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 113304 - perl should not export -D_FILE_OFFSET_BITS=64
perl should not export -D_FILE_OFFSET_BITS=64
Product: Fedora
Classification: Fedora
Component: perl (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
David Lawrence
Depends On:
Blocks: FC5Blocker
  Show dependency treegraph
Reported: 2004-01-12 08:11 EST by Joe Orton
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version: ALL
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-11-10 14:13:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Joe Orton 2004-01-12 08:11:56 EST
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 04:12:03 EST
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 03:34:35 EST
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-21 22:24:05 EDT
Is this still an issue with the latest perl, or perl in FC2?
Comment 4 Joe Orton 2004-04-22 04:00:54 EDT
$ 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 19:57:12 EDT
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 08:30:40 EDT
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 17:26:15 EDT
> 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 04:10:50 EDT
Hard because it means messing with Perl internals.  I don't know 
Comment 9 Warren Togami 2005-10-17 23:05:39 EDT
Hey Chip, any recommendations for what to do on this?
Comment 10 Jason Vas Dias 2005-11-10 14:13:01 EST
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.

Note You need to log in before you can comment on or make changes to this bug.