Edit report at https://bugs.php.net/bug.php?id=65948edit=1
ID: 65948
Comment by: wzis at hotmail dot com
Reported by:wzis at hotmail dot com
Summary:extension and PHP API version mismatch
Status: Wont fix
Type: Bug
Package:*General Issues
Operating System: Linux
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
It's not that simple to just have 5 modules for 5.1, 5.2, 5.3, 5.4, 5.5: for
AIX/HP-UX 9000/IA64/Solaris Sparc/X86, Linux X86/ARM/Power, that means we have
to maintain 40 modules, in stead of just one module for each platform, and in
total just 8.
Yes, Linux kernel does change very frequently, but for commercial Linux, like
RHEL, they know this is a problem, so they will try to maintain the kernel
API/ABI compatibility within each major release as much as possible, they won't
just get a latest kernel from the kernel.org and let user to upgrade the kernel
like that.
Previous Comments:
[2013-10-24 23:04:35] yohg...@php.net
Just an additional note for Linux distributions.
AFAIK, all Linux distributions have strict version match policy for modules.
This is not a PHP limitation, but distributor's limitations. (e.g. Modules
built with PHP 5.5.5 requires PHP 5.5.5, not 5.5.x.) They add strict version
dependency even if PHP itself does not require it.
You don't have to follow Linux distributors limitation.
[2013-10-24 22:55:16] yohg...@php.net
PHP script is the application. PHP is the OS for PHP applications.
Linux applications run on very long term as well as PHP applications. libc is
like a framework that wraps incompatibility between PHP versions.
If you use NVidia native driver for X, you'll notice that Linux kernel changes
internal API/ABI often and source code has to be modified. Internal API/ABI
needed to be changed to fix bugs and improve features, performance, etc.
If you would like to provide modules work under versions of PHP, for instance
5.3.x, 5.4.x and 5.5.x, you only have to maintain 3 binaries for 5.3.x, 5.4.x
and 5.5.x. To keep compatibility between 5.3.x, 5.4.x and 5.5.x, you will needs
only handful #if/#ifdef and no need for 3 sources but one. It should not be
hard jobs for C programmers.
[2013-10-24 22:35:46] ni...@php.net
Thanks for your insights as to how not providing ABI-compatibility on par with
operating systems results in worst of any computer programming language
API/ABI's compatibility (because operating systems are the same as programming
langues, obviously).
PHP provides about the same guarantees that Python does: API/ABI compat for
x.y.z+1 and mostly-source-compat for x.y+1.z.
[2013-10-24 22:13:08] wzis at hotmail dot com
Not very true: On UNIX/Linux systems, you can still have multiple versions of
libc installed at different locations if that is really you need, and you can
let a program to use the version of libc by setting LD_LIBRARY_PATH: but since
on UNIX/Linux systems, the API backward compatibility is maintained very well,
there is no such need to install a different version of libc in normal
situation.
On Solaris, a program binary built on Solaris 8 can still work on Solaris 11,
that's more than 15 years in time span.
As for ABI compatibility, even freebsd wants to make ABI compatible with Linux.
So the PHP's way of only maintaining API (in your sense may be ABI, but this is
even on same platform even with same OS version) compatibility within just the
x.y.z for all z, that's the worst of any computer programming language
API/ABI's compatibility.
[2013-10-24 10:55:17] johan...@php.net
First: Please don't confuse ABI and API compatibility. API compatibility we
have to a way larger degree. So many things just need a recompilation. ABI,
binary compatibility is what we are talking about.
Yes, operating system core APIs have quite some restrictions on ABI
compatibility, this leads to some maintenance hell in some areas like use of
special #defines to enable specific features or bug fixes or ...
There the restrictions make sense - you can run only one libc on a host. With
PHP this isn't the case.
That said: We are aware of the fact that we might do better by having a
stricter defined API and keeping that stable. For none of the active
contributors (who are volunteers) this is not a big issue, though. If you want
to help in that area this is welcome. Some basic thoughts are in these RFCs:
https://wiki.php.net/rfc/php_native_interface
https://wiki.php.net/rfc/remove_zend_api
