Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.5.0

Bug #20246 Broken with php 5.5.9
Submitted: 2014-04-19 15:50 UTC
From: gbc Assigned: mrook
Status: Closed Package: Archive_Tar (version 1.3.11)
PHP Version: 5.5.9 OS: Ubuntu 14.04
Roadmaps: 1.3.12    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 45 - 5 = ?

 
 [2014-04-19 15:50 UTC] gbc (Grey Box)
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

Comments

 [2014-04-19 15:55 UTC] gbc (Grey Box)
$ 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
 [2014-04-19 20:49 UTC] mrook (Michiel Rook)
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.
 [2014-04-26 20:31 UTC] doconnor (Daniel O'Connor)
-Status: Open +Status: Feedback
 [2014-05-08 18:39 UTC] mo (Markus Ungersboeck)
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?
 [2014-05-08 20:01 UTC] mo (Markus Ungersboeck)
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.
 [2014-05-08 20:06 UTC] mrook (Michiel Rook)
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)
 [2014-05-09 12:16 UTC] mo (Markus Ungersboeck)
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
 [2014-07-23 00:42 UTC] dmausner (dave mausner)
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.
 [2014-07-23 02:10 UTC] cweiske (Christian Weiske)
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.
 [2014-07-23 06:45 UTC] dmausner (dave mausner)
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.
 [2014-07-23 11:51 UTC] mrook (Michiel Rook)
-Roadmap Versions: +Roadmap Versions: 1.3.12
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.
 [2014-07-29 18:02 UTC] mrook (Michiel Rook)
I've pushed https://github.com/pear/Archive_Tar/commit/22431e47455c0a703c6145a38553d7 202a9cde10, can someone review that commit? Thanks.
 [2014-07-30 08:49 UTC] dmausner (dave mausner)
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.
 [2014-08-01 17:23 UTC] mrook (Michiel Rook)
I've changed the implementation to https://github.com/pear/Archive_Tar/commit/06e7b69bbe670bb3695fdde75e7937 d1e5295de2, please review.
 [2014-08-04 16:14 UTC] mrook (Michiel Rook)
-Status: Feedback +Status: Closed -Assigned To: +Assigned To: mrook
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.