Bug 113304 - perl should not export -D_FILE_OFFSET_BITS=64
Summary: perl should not export -D_FILE_OFFSET_BITS=64
Alias: None
Product: Fedora
Classification: Fedora
Component: perl
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jason Vas Dias
QA Contact: David Lawrence
Depends On:
Blocks: FC5Blocker
TreeView+ depends on / blocked
Reported: 2004-01-12 13:11 UTC by Joe Orton
Modified: 2007-11-30 22:10 UTC (History)
4 users (show)

Fixed In Version: ALL
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-11-10 19:13:01 UTC
Type: ---

Attachments (Terms of Use)

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.

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