Bug 212804 - RFE: php should provides "Zend Module Api No"
RFE: php should provides "Zend Module Api No"
Product: Fedora
Classification: Fedora
Component: php (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2006-10-29 02:31 EST by Remi Collet
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-01-03 08:18:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Remi Collet 2006-10-29 02:31:28 EST
Description of problem:
php only provide "PHP Api Version" (php-api). This value still the same across
version, while "Zend Module Api No" change.

At load time, php check "Zend Module Api Version".

For example, when trying to load a extension, build with php-5.2.0, on
php-5.1.6, a sanity check refuse to load the extension

# php -v
PHP Warning:  PHP Startup: mailparse: Unable to initialize module
Module compiled with module API=20060613, debug=0, thread-safety=0
PHP    compiled with module API=20050922, debug=0, thread-safety=0
These options need to match

I think it would be better to handle this with Requires/Provides in the RPM spec

For exemple, in php.spec
%define zendver 20050922
Provides: php-zendapi = %{zendver}
vzend=$(sed -n '/#define PHP_API_VERSION/{s/.* //;p}' main/php.h)
if test "x${vzend}" != "x%{zendver}"; then
   : Error: Upstream Zend Module API version is now ${vapi}, expecting %{apiver}.
   : Update the zendver macro and rebuild.
   exit 1

And in a pecl extension specfile :
%global php_zendver  %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP Extension =>
//p') | tail -1)

Requires: php-zendapi = %{php_zendver}

There is also "Zend Extension Api No" (220051025), but i don't know when this
value is used.

Comment 1 Remi Collet 2006-11-16 11:53:30 EST
I saw version 5.2.0-4 is on rawhide, great.

This provides php-zend-abi = "Zend Extension Api No"
Why not the "Zend Module Api No" (ZEND_MODULE_API_NO define in
Zend/zend_modules.h) as the check seems made on this value.

I must apologize, my example int the bug report was not correct (don't search
for the good value).

sed -n '/#define PHP_API_VERSION/{s/.* //;p}' main/php.h
sed -n '/#define ZEND_MODULE_API_NO/{s/.* //;p}' Zend/zend_modules.h
sed -n '/#define ZEND_EXTENSION_API_NO/{s/^[^0-9]*//;p;}' Zend/zend_extensions.h

Comment 2 Remi Collet 2006-11-18 02:19:02 EST
I confirm that it's ZEND_MODULE_API_NO which is first needed.

Each pecl extension include an "zend_module_entry" object.
Second member is "zend_api". Value is ZEND_MODULE_API_NO (included in

ext/standard/php_dl.c (in function php_dl) check this value.

> module_entry->zend_api != ZEND_MODULE_API_NO

Same safety check is done in ./Zend/zend_extensions.c with
ZEND_EXTENSION_API_NO, but i don't find any extension using a
Comment 3 Joe Orton 2006-11-27 11:34:02 EST
php-5.1.6-3.2.fc6 has been pushed to FC6 updates-testing, which should contain
the fix for this bug.  You can test the new packages by running:

  # yum --enablerepo=updates-testing update php

Comment 4 Remi Collet 2006-12-05 10:37:40 EST
Have you more information about ZEND_MODULE_API_NO vs ZEND_EXTENSION_API_NO
(comment #2) ?

I've also test php-5.2.0-7 from rawhide.
Providing /etc/rpm/macros.php is really a good idea.

Comment 5 Joe Orton 2006-12-05 10:49:32 EST
Ah, good catch Remi, you're correct, thanks, I'll fix that.
Comment 6 Remi Collet 2007-01-02 13:38:54 EST

After the Fedora Extras Packaging Commitee, 
members wants to be consistent with other langages virtual provides. :
Can you update php to provide :
Provides: php-api = %{apiver}, php(api) = %{apiver}, php(zend-abi) = %{zendver}
(php-api is used for a very long time, php(..) will be used for packaging

Can you also add the macros.php to FC-6 version ?

Comment 7 Joe Orton 2007-01-03 08:18:26 EST
Can you file new bugs for those two requests, and include a link to the
Packaging discussion for the first issue?  This bug is being used to track too
much :)
Comment 8 Raul Drelichman 2007-01-13 17:01:28 EST
Dear Sirs
WE have the same problem, php-mysql package was compiled with diferent API than
php package.

I can't find any newer package than php-mysql-5.2.0-8.x86_64.rpm that returns
the error message
Unable to initialize module\nModule compiled with module API=20050922, debug=0,
thread-safety=0\nPHP    compiled with module API=20060613, debug=0,
thread-safety=0\nThese options need to match\n in Unknown on line 0

Please can you give us information if this error was solved in any package for
x86_64 architecture.

Thank You
Raul Drelichman (raul@drelichman.com) 
Comment 9 Remi Collet 2007-01-14 01:36:28 EST

php-mysql requires exact version of php-common. You shouldn't have this issue
(which is pecl extension related).

It seems you have installed php-myql with --nodeps or --force option with
php-5.1.6 installed.

Comment 10 Raul Drelichman 2007-01-14 04:07:43 EST

No, I installed the modules in the correct order, i.e., in frst time php-common
5.2.0.-8 (and first the modules needed by this i rememeber php-cli also) then
php 5.2.0.-8 and the last one php-mysql 5.2.0.-8 without use the --force or
--nodeps options.

Do you consider that I need to do a clean install of all. uninstaling all the
modules and reinstaling from zero?

Thank again for giving your experience to us

Raul Drelichman

Note You need to log in before you can comment on or make changes to this bug.