Description: ------------ Same problem as described here: http://cweiske.de/tagebuch/pear-php-5.5.htm Can't do anything with pear which uses Archive_Tar (installing, upgrading, etc). Patch from here https://pear.php.net/bugs/bug.php?id=19746&edit=12&patch=archive_tar_php55.patch&revision=1355241213 applied, no difference. Also tried upgrade from https://github.com/pear/Archive_Tar . No change. $ pear info archive_tar|head -n1 ABOUT PEAR.PHP.NET/ARCHIVE_TAR-1.3.11

$ php -v PHP 5.5.9-1ubuntu4 (cli) (built: Apr 9 2014 17:08:27) Copyright (c) 1997-2014 The PHP Group Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans

Hi, Could you clone https://github.com/pear/Archive_Tar and do "cd tests && pear run- tests"? Do the tests run? I have the exact same setup (Ubuntu 14.04 / PHP 5.5.9) and can't reproduce this.

I'm not gbc but I have also some problems after the Ubuntu upgrade (Ubuntu 14.04 / PHP 5.5.9). I've tried the recommended test and one failed FAIL test files that happen to contain the endblock[invalidblock.phpt further suggestions?

Just as add on, at least for my installation gzopen is broken in the current Ubuntu php version php -r 'var_dump(function_exists("gzfile"));' bool(true) php -r 'var_dump(function_exists("gzopen"));' bool(false) php -r 'var_dump(function_exists("gzopen64"));' bool(true) as you can find a lot of bug reports currently in the Ubuntu/php community I guess it's a very common problem. Checking and replacing gzopen by gzopen64 might help until Ubuntu submit a patch.

Very strange: $ php -v PHP 5.5.9-1ubuntu4 (cli) (built: Apr 9 2014 17:11:57) Copyright (c) 1997-2014 The PHP Group Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans $ php -r 'var_dump(function_exists("gzopen"));' bool(true) $ php -r 'var_dump(function_exists("gzopen64"));' bool(false)

Well my php built is 3min older php -v PHP 5.5.9-1ubuntu4 (cli) (built: Apr 9 2014 17:08:27) Copyright (c) 1997-2014 The PHP Group Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies so I uninstalled php, switched the repository back from the Austrian mirror, installed php and got the 17:08:27 built again

Tar.php contains references to gzopen, gztell, and gzseek, which may be renamed gzopen64, gztell64, and gzseek64, depending on whose php5 build you have installed. It currently calls the functions without '64', hence if the build contains only the functions with '64', Tar.php aborts. A simple and ugly solution is to modify Tar.php to check for the existence of each function by name, with and without the '64', and then execute whichever. There are half-a-dozen code blocks to insert where these functions are used.

The PHP bug report is https://bugs.php.net/bug.php?id=53829 and it's from 2011. Doesn't seem like it's going away soon. We could provide a wrapper that simply defines gzopen() and internally passes the data through to gzopen64.

Agreed. Someone with write privs on the code, please update the package to either wrap the functions or check at each call. The point is, the solution must work in either a 32 or 64 build.

I'm putting this on a roadmap. While I don't like wrapping those calls, I don't think we have any alternative with those function signatures.

I've pushed https://github.com/pear/Archive_Tar/commit/22431e47455c0a703c6145a38553d7 202a9cde10, can someone review that commit? Thanks.

CW, lines 814 & 888 are incorrect. The previous code used function_exists() and so does the new wrapper. Therefore, if gzopen64 exists, gzopen does not exist, and your new wrapper will not get called. Then the code will soft-abort. Suggestion: remove the original function_exists() calls.

I've changed the implementation to https://github.com/pear/Archive_Tar/commit/06e7b69bbe670bb3695fdde75e7937 d1e5295de2, please review.

This bug has been fixed in SVN. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.