#39372 [NEW]: Incompatibility in the PHP API.
| From: | cm at cmunt dot demon dot co dot uk | 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 doesnt appear to be any
technical reason why this should be the case after all, Ive 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