php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #53829 Compiling PHP with large file support will replace function gzopen by gzopen64
Submitted: 2011-01-24 14:40 UTC Modified: 2014-11-11 12:35 UTC
Votes:19
Avg. Score:4.6 ± 0.6
Reproduced:16 of 17 (94.1%)
Same Version:4 (25.0%)
Same OS:10 (62.5%)
From: rilatonal at hotmail dot de Assigned: mbeccati (profile)
Status: Closed Package: Zlib related
PHP Version: 5.3.5 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: rilatonal at hotmail dot de
New email:
PHP Version: OS:

 

 [2011-01-24 14:40 UTC] rilatonal at hotmail dot de
Description:
------------
I am in the need of supporting large files in PHP.
For the first time I tried to compile PHP on a machine with zlib 1.2.5 installed.


After that, gzopen (and the other gz.. functions) is gone and is being replaced by gzopen64 (or the other gz...64-functions).

Thats a big problem, because many PEAR-scripts (and other scripts, too) expect gzopen to be there!

ZLIB is there (see the test scripts), but gzopen not!


Test script:
---------------
CFLAGS="-g -O3 -m32 -D_FILE_OFFSET_BITS=64" ./configure --prefix=/tmp/php --with-config-file-path=/tmp/php/etc --disable-all -with-zlib
make
make install

/tmp/php/bin/php -r 'var_dump(function_exists("gzopen"));'
/tmp/php/bin/php -r 'var_dump(function_exists("gzopen64"));'

/tmp/php/bin/php -r '$fp = fopen("compress.zlib://hello-world.txt.gz", "wb"); fwrite($fp, "Hello World!\n"); fclose($fp);'
zcat hello-world.txt.gz

Expected result:
----------------
I expect gzopen to be there!


Actual result:
--------------
gzopen is being replaced by gzopen64!


Patches

zlib-largefile-function-renaming (last revision 2013-02-08 12:24 UTC by skettler@php.net)
gzopen64 (last revision 2012-08-26 10:57 UTC by comments at sentfrom dot com)

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-05-27 17:06 UTC] j dot henge-ernst at interexa dot de
I also encountered that problem compiling php on solaris x86_64 with zlib 1.2.5. I used the following configure commmand:

#! /bin/sh
#
# Created by configure

CFLAGS='-xmodel=small -m64 -Kpic -O4' \
CXXFLAGS='-xmodel=small -m64 -Kpic -O4' \
LDFLAGS='-m64' \
CC='cc' \
'./configure' \
'--prefix=/opt/IXAGib64' \
'--with-config-file-path=/opt/IXAGib64/etc' \
'--with-config-file-scan-dir=/opt/IXAGib64/etc/php.ini.d' \
'--disable-debug' \
'--enable-inline-optimization' \
'--disable-all' \
'--enable-ctype' \
'--enable-dom' \
'--enable-libxml' \
'--with-libxml-dir=/opt/IXAGib64' \
'--with-openssl=/opt/IXAGib64' \
'--with-pcre-regex' \
'--enable-session' \
'--enable-simplexml' \
'--enable-wddx' \
'--enable-xml' \
'--enable-hash' \
'--enable-json' \
'--enable-filter' \
'--with-zlib=/opt/IXAGib64' \
'--with-apxs2=/opt/IXAGib64/bin/apxs' \
'--with-pear' \
'--with-layout=GNU' \
"$@"
 [2011-09-07 07:09 UTC] tx-7-12 at tuxad dot com
Hi,

I also got this "bug" with the latest zlib 1.2.5 as system lib and "-D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE=1".

Dirty solution: Define ZLIB_INTERNAL.

# /usr/local/php/bin/php -r 'var_dump(function_exists("gzopen"));'
bool(false)
# export CFLAGS="... -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE=1 -DZLIB_INTERNAL=1"
configure && make
# sapi/cli/php -r 'var_dump(function_exists("gzopen"));'
bool(true)

Matching lines in zlib.h:

#if !defined(ZLIB_INTERNAL) && _FILE_OFFSET_BITS-0 == 64 && _LFS64_LARGEFILE-0
#  define gzopen gzopen64
#  define gzseek gzseek64
#  define gztell gztell64
#  define gzoffset gzoffset64
#  define adler32_combine adler32_combine64
#  define crc32_combine crc32_combine64
#  ifdef _LARGEFILE64_SOURCE
     ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *));
     ZEXTERN z_off_t ZEXPORT gzseek64 OF((gzFile, z_off_t, int));
     ZEXTERN z_off_t ZEXPORT gztell64 OF((gzFile));
     ZEXTERN z_off_t ZEXPORT gzoffset64 OF((gzFile));
     ZEXTERN uLong ZEXPORT adler32_combine64 OF((uLong, uLong, z_off_t));
     ZEXTERN uLong ZEXPORT crc32_combine64 OF((uLong, uLong, z_off_t));
#  endif
#else
   ZEXTERN gzFile ZEXPORT gzopen OF((const char *, const char *));
   ZEXTERN z_off_t ZEXPORT gzseek OF((gzFile, z_off_t, int));
   ZEXTERN z_off_t ZEXPORT gztell OF((gzFile));
   ZEXTERN z_off_t ZEXPORT gzoffset OF((gzFile));
   ZEXTERN uLong ZEXPORT adler32_combine OF((uLong, uLong, z_off_t));
   ZEXTERN uLong ZEXPORT crc32_combine OF((uLong, uLong, z_off_t));
#endif

Frank
 [2012-08-26 11:07 UTC] comments at sentfrom dot com
I encountered the same problem with a 64-bit build of PHP on OpenIndiana
b151. 
The symptom I saw was Wordpress automatic updates were failing silently, because 
the class-pclzip.php module tests for the presence of gzopen. 
Patching that file is not a viable option since any WP update can overwrite it 
again.

The gzopen patch attached fixes this at the PHP level by using lower-level ZEND 
macros that are not affected by zlib.h's #define gzopen gzopen64. It 
is preferable to using an undocumented zlib compilation flag ZLIB_INTERNAL, 
which may go away at some point in the future.

I had to use ZEND_RAW_FENTRY as it does not have a PHP_ equivalent, and we have 
to pass the first argument "gzopen" as a string, since cpp would 
replace gzopen with gzopen64 if passed as a C identifier.
 [2013-02-08 12:24 UTC] skettler@php.net
The following patch has been added/updated:

Patch Name: zlib-largefile-function-renaming
Revision:   1360326291
URL:        https://bugs.php.net/patch-display.php?bug=53829&patch=zlib-largefile-function-renaming&revision=1360326291
 [2013-02-08 12:26 UTC] skettler@php.net
Added patch "zlib-largefile-function-renaming" that fixes the gzopen, gzseek and 
gztell PHP function renaming.
 [2013-03-03 00:25 UTC] bjori@php.net
-Assigned To: +Assigned To: skettler
 [2013-03-03 00:25 UTC] bjori@php.net
skettler: Any need for that ifdef? Can't we always use the RAW macro?
And what about the other functions he mentioned in this report?
 [2014-07-03 15:42 UTC] anthon at piwik dot org
+1

This appears to be a problem with Ubuntu Trusty32 (zlib 1.2.8) where php appears to now expose gzopen64.  (See http://dev.piwik.org/trac/ticket/5407)

skettler's patch fixes this by undefining the problematic macros.

(The other functions: gzoffset, adler32_combine, and crc32_combine are not used in the extension, ext/zlib/*)
 [2014-08-20 23:24 UTC] jj9305 at att dot com
It also affects HP-UX version 5.5.11 (a real pain to get to build due to other problems, btw)
$ php_5.5.11 -a
Interactive shell

php > var_dump( extension_loaded( 'zlib' ) );
bool(true)
php > $f = gzopen( '/tmp/gf.gz', 'r' );

Fatal error: Call to undefined function gzopen() in php shell code on line 1
 [2014-11-11 12:35 UTC] mbeccati@php.net
-Assigned To: skettler +Assigned To: mbeccati
 [2014-11-12 10:24 UTC] mbeccati@php.net
Automatic comment on behalf of mbeccati
Revision: http://git.php.net/?p=php-src.git;a=commit;h=65fee904622160781db05b0a469d67b4414cbd7f
Log: Fixed bug #53829 Compiling PHP with large file support will replace function gzopen by gzopen64
 [2014-11-12 10:24 UTC] mbeccati@php.net
-Status: Assigned +Status: Closed
 [2014-11-18 20:34 UTC] ab@php.net
Automatic comment on behalf of mbeccati
Revision: http://git.php.net/?p=php-src.git;a=commit;h=65fee904622160781db05b0a469d67b4414cbd7f
Log: Fixed bug #53829 Compiling PHP with large file support will replace function gzopen by gzopen64
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 13:01:29 2024 UTC