#39372 [NEW]: Incompatibility in the PHP API.

From: Date: Sat, 04 Nov 2006 09:49:59 +0000
Subject: #39372 [NEW]: Incompatibility in the PHP API.
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-104372@lists.php.net to get a copy of this message
From: cm at cmunt dot demon dot co dot uk Operating system: All PHP version: 5.2.0 PHP Bug Type: *Compile Issues Bug description: Incompatibility in the PHP API. Description: ------------ You will probably not regard this issue as bug and it is something that you are no doubt already aware of but it is a problem that, in our experience, causes no end of confusion and frustration among many users of PHP. The issue is this: pretty much every new release of PHP (including a significant number of minor upgrades) requires that all third party extension modules be rebuilt from source. There doesn’t appear to be any technical reason why this should be the case – after all, I’ve yet to see a situation where module code has to be changed on upgrade. This is a huge nuisance – particularly since many PHP systems these days are either pre-installed in binary form or tend to be distributed as pre-built kits (e.g. Windows). The requirement to rebuild could be removed by abstracting the data structures used in the PHP API to a higher level – in much the same was as Microsoft has done with ISAPI extensions to IIS. Incidentally, I seem to remember the PHP community being up in arms in the early days of Apache v2 when every minor upgrade (2.0.x) required third party Apache modules to be rebuilt – i.e. the PHP DSO. In the end the Apache Group capitulated and properly abstracted the API such that a rebuild would only be necessary between _major_ upgrades. This brings me to another problem with PHP: there seems to be no way of telling in advance whether or not third party modules will need rebuilding. Sometimes a minor upgrade will require a module rebuild; sometimes not. A little more effort and/or rationalization in this area would be much appreciated ! -- Edit bug report at http://bugs.php.net/?id=39372&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39372&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39372&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39372&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39372&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39372&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39372&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=39372&r=needscript Try newer version: http://bugs.php.net/fix.php?id=39372&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39372&r=support Expected behavior: http://bugs.php.net/fix.php?id=39372&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39372&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39372&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39372&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39372&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39372&r=dst IIS Stability: http://bugs.php.net/fix.php?id=39372&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39372&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39372&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39372&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=39372&r=mysqlcfg

« previous php.bugs (#104372) next »