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' \
"$@"

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

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.

Added patch "zlib-largefile-function-renaming" that fixes the gzopen, gzseek and 
gztell PHP function renaming.

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?

+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/*)

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