Bug 113304

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>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	cturner, mitr, perl-devel, wtogami
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
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:
Embargoed:
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-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.