php and LFS

Jakub Bogusz qboosh at
Thu May 15 19:08:10 CEST 2014

On Wed, May 14, 2014 at 09:47:42PM +0300, Elan Ruusamäe wrote:
> On 14.05.2014 21:20, Elan Ruusamäe wrote:
> >On 14.05.2014 16:47, Jakub Bogusz wrote:
> >>On Wed, May 14, 2014 at 02:43:23PM +0300, Elan Ruusamäe wrote:
> >>>but, i do see -D_GNU_SOURCE -D_LARGEFILE64_SOURCE in build logs... 
> >>>ideas?
> >>_LARGEFILE64_SOURCE enables 64-bit file API, but with separate names.
> >>To get them available under base names, _FILE_OFFSET_BITS=64 must be
> >>used.
> >
> >
> >is it safe to add it to CFLAGS?
> >
> >i found this ticket
> >
> and this one
> also the LFS flags found from log came from apr config:
> /usr/bin/apr-1-config:CPPFLAGS="-DLINUX -D_REENTRANT -D_GNU_SOURCE 
> php itself has PHP_SYS_LFS macro in acinclude.m4, but it's never 
> referenced in php-src
> the getconf class, that it would use are:
> $ getconf LFS_CFLAGS
> $  getconf LFS_LDFLAGS
> $  getconf LFS_LIBS
> $
> if we rebuild with "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64", will that:
> 1) decrease performance of php as said in bug 45942

What complete flags were used? In this report I see
CFLAGS="-D_FILE_OFFSET_BITS=64" ./configure ...
which could disable any compiler optimization which configure uses by
default (if custom PHP configure code doesn't set any if there are no
-Ox options in CFLAGS).

> 2) would require rebuild all php extensions? or funny things will happen?

Depends if off_t, struct stat or so are used in ABI.

Also note that the flag itself is (probably) sufficient to get 64-bit
inode support, but not for complete 64-bit file offsets/lengths support.
For the latter, you can find some patch here:
in particular:

(partially ugly, like returning sizes as doubles, but it seems to be PHP

Jakub Bogusz

More information about the pld-devel-en mailing list