Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:32775
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain redhat.com designates 66.187.233.31 as permitted sender)
Date: Mon, 15 Oct 2007 11:43:55 +0100
To: internals@lists.php.net
Message-ID: <20071015104355.GA11745@redhat.com>
Mail-Followup-To: internals@lists.php.net
References: <64ED731E-CA44-498E-9AF9-C9B00037B863@omniti.com> <47131626.5020809@sektioneins.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <47131626.5020809@sektioneins.de>
User-Agent: Mutt/1.5.14 (2007-02-12)
Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom.
  Registered in UK and Wales under Company Registration No. 03798903
  Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson (USA), Charlie Peters (USA)
Subject: Re: [PHP-DEV] Large file support for PHP
From: jorton@redhat.com (Joe Orton)

On Mon, Oct 15, 2007 at 09:26:30AM +0200, Stefan Esser wrote:
> Hi,
> 
> please keep in mind that compiling PHP with large file support breaks
> binary compatibility...
> One of the globals contain a "stat" struct that has different size for
> LFS or no LFS.

More harmfully, it also changes the ABI of any library/application 
linked against PHP where that ABI uses off_t.  So PHP would see all 
off_t's in the libraries API as 64-bit, whereas they were built as 
32-bit.  This breaks structure offsets etc very badly.

The way this is done for e.g APR avoids the issue; using only 
-D_LARGEFILE64_SOURCE, off64_t in place of off_t, and fstat64, 
open64/O_LARGEFILE, etc.

joe