FAQ
I see the module API has changed between 5.0 and 5.1. This caused my
module to fail to load with:

PHP Warning: PHP Startup: z\x17\xfc\xb6d\x12\xfc\xb6: Unable to initialize module
Module compiled with module API=20041030, debug=0, thread-safety=0
PHP compiled with module API=20050922, debug=0, thread-safety=0
These options need to match
in Unknown on line 0

Obviously this is problematic when shipping binaries. Basically I now
have modules for 4, 5.0, and 5.1 in my installation package and look at
phpversion() to determine which one to install.

Are these module changes very common?

Is there an easier way to ship module binaries?

Is the major verion number guaranteed to change when the module API
changes?

Are there any other module API changes between 4 and the current version
of PHP that would cause my module to fail to load?

Thanks,
Mike

--
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/

Search Discussions

  • Pierre at Sep 14, 2006 at 2:49 pm
    Hello,
    On 9/14/06, Michael B Allen wrote:

    Are there any other module API changes between 4 and the current version
    of PHP that would cause my module to fail to load?
    PHP internals API has many changes between two major versions. Don't
    expect a module compiled for php4 to be loaded smoothly in php5, the
    same applies from one minor version to another. You have to provide a
    binary per minor version, and for debug or non debug builds, like any
    other DLL/so.

    (5.0 and 5.1 are php5 minor versions, for example)

    --Pierre
  • Michael B Allen at Sep 14, 2006 at 5:15 pm

    On Thu, 14 Sep 2006 16:49:16 +0200 Pierre wrote:

    Hello,
    On 9/14/06, Michael B Allen wrote:

    Are there any other module API changes between 4 and the current version
    of PHP that would cause my module to fail to load?
    PHP internals API has many changes between two major versions. Don't
    expect a module compiled for php4 to be loaded smoothly in php5, the
    same applies from one minor version to another. You have to provide a
    binary per minor version, and for debug or non debug builds, like any
    other DLL/so.

    (5.0 and 5.1 are php5 minor versions, for example)
    Sorry, I meant to say minor version. So the minor version will change
    if the module API changes?

    Our module compiles without modifcation with 4, 5.0, and 5.1.

    Is it possible to load a module compiled with a ZEND_MODULE_API_NO that
    differs from the one PHP was compiled with?

    Is it possible for a module compiled with debugging to be loaded in a
    debug build of PHP?

    It's not a horribly big deal to ship 3 modules but it would be nice if
    our package had a level of forward compatibility (e.g. worked with a
    new snapshot that introduced a moduel API change).

    Has the module API changed in 5.2?

    Thanks,
    Mike

    --
    Michael B Allen
    PHP Active Directory SSO
    http://www.ioplex.com/
  • Pierre at Sep 14, 2006 at 5:19 pm
    Hello,
    On 9/14/06, Michael B Allen wrote:
    On Thu, 14 Sep 2006 16:49:16 +0200
    Pierre wrote:
    Hello,
    On 9/14/06, Michael B Allen wrote:

    Are there any other module API changes between 4 and the current version
    of PHP that would cause my module to fail to load?
    PHP internals API has many changes between two major versions. Don't
    expect a module compiled for php4 to be loaded smoothly in php5, the
    same applies from one minor version to another. You have to provide a
    binary per minor version, and for debug or non debug builds, like any
    other DLL/so.

    (5.0 and 5.1 are php5 minor versions, for example)
    Sorry, I meant to say minor version. So the minor version will change
    if the module API changes?

    Our module compiles without modifcation with 4, 5.0, and 5.1.
    Some of mines too. The problem is not to compile but to load it.
    Is it possible to load a module compiled with a ZEND_MODULE_API_NO that
    differs from the one PHP was compiled with? No
    Is it possible for a module compiled with debugging to be loaded in a
    debug build of PHP? Neither
    It's not a horribly big deal to ship 3 modules but it would be nice if
    our package had a level of forward compatibility (e.g. worked with a
    new snapshot that introduced a moduel API change).
    If it a snapshot have a new API, it will also have a new API version
    and will be available in a new minor/major PHP version.
    Has the module API changed in 5.2?
    Yes, if not it will still be 5.1.x. I think the changes will be
    explained in the README.UPDATE_5_2 file in CVS, or they are already
    in.

    --Pierre
  • Steph Fox at Sep 14, 2006 at 5:30 pm
    Hi Michael, Pierre -

    Erm, no they aren't in the upgrade guide, because the upgrade guide is aimed
    at user issues and this was seen primarily as an extension author issue. Do
    people generally think the module and extension API bumps should be in
    there?

    - Steph
    Hello,
    On 9/14/06, Michael B Allen wrote:
    On Thu, 14 Sep 2006 16:49:16 +0200
    Pierre wrote:
    Hello,
    On 9/14/06, Michael B Allen wrote:

    Are there any other module API changes between 4 and the current
    version
    of PHP that would cause my module to fail to load?
    PHP internals API has many changes between two major versions. Don't
    expect a module compiled for php4 to be loaded smoothly in php5, the
    same applies from one minor version to another. You have to provide a
    binary per minor version, and for debug or non debug builds, like any
    other DLL/so.

    (5.0 and 5.1 are php5 minor versions, for example)
    Sorry, I meant to say minor version. So the minor version will change
    if the module API changes?

    Our module compiles without modifcation with 4, 5.0, and 5.1.
    Some of mines too. The problem is not to compile but to load it.
    Is it possible to load a module compiled with a ZEND_MODULE_API_NO that
    differs from the one PHP was compiled with? No
    Is it possible for a module compiled with debugging to be loaded in a
    debug build of PHP? Neither
    It's not a horribly big deal to ship 3 modules but it would be nice if
    our package had a level of forward compatibility (e.g. worked with a
    new snapshot that introduced a moduel API change).
    If it a snapshot have a new API, it will also have a new API version
    and will be available in a new minor/major PHP version.
    Has the module API changed in 5.2?
    Yes, if not it will still be 5.1.x. I think the changes will be
    explained in the README.UPDATE_5_2 file in CVS, or they are already
    in.

    --Pierre

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Pierre at Sep 14, 2006 at 5:39 pm
    Hello,
    On 9/14/06, Steph Fox wrote:
    Hi Michael, Pierre -

    Erm, no they aren't in the upgrade guide, because the upgrade guide is aimed
    at user issues and this was seen primarily as an extension author issue. Do
    people generally think the module and extension API bumps should be in
    there?
    Rasmus was talking about the internals change and ask if they can be
    put in this file. I think it is a very good suggestion and no, I did
    not have the time (and will not in the next 10 days) to do it :)

    --Pierre
  • Steph Fox at Sep 14, 2006 at 6:06 pm
    OK, has anyone enough time to commit this please?

    I left the extension API change out of it though (the ME_* support) - does
    that really need to go in there too?

    ----- Original Message -----
    From: "Pierre" <pierre.php@gmail.com>
    To: "Steph Fox" <steph@zend.com>
    Cc: "Michael B Allen" <mba2000@ioplex.com>; <internals@lists.php.net>
    Sent: Thursday, September 14, 2006 7:39 PM
    Subject: Re: [PHP-DEV] Module API Changes

    Hello,
    On 9/14/06, Steph Fox wrote:
    Hi Michael, Pierre -

    Erm, no they aren't in the upgrade guide, because the upgrade guide is
    aimed
    at user issues and this was seen primarily as an extension author issue.
    Do
    people generally think the module and extension API bumps should be in
    there?
    Rasmus was talking about the internals change and ask if they can be
    put in this file. I think it is a very good suggestion and no, I did
    not have the time (and will not in the next 10 days) to do it :)

    --Pierre
  • Pierre at Sep 14, 2006 at 6:14 pm
    Hello,
    On 9/14/06, Steph Fox wrote:
    OK, has anyone enough time to commit this please?

    I left the extension API change out of it though (the ME_* support) - does
    that really need to go in there too?
    This thread justifies the addition (and all other about the same topic :).
  • Steph Fox at Sep 14, 2006 at 6:26 pm
    Huh?

    The question was about module API change, which is transparent to anyone
    mixing and matching PHP and module versions (which incidentally they
    shouldn't be doing in the first place). The extension API doesn't matter to
    anyone but extension authors... and actually I can't remember if the code
    for that retained BC off-hand too... need to check...

    There were a handful of minor API breakages that I vaguely remember fixing
    for PHP-GTK back then, but they came under the 'extension API bump'
    mbrella - in other words, they were ignored in their own right. Again,
    these were things that would be evident to an extension maintainer rather
    than an end user - and everything there would be better covered in
    README.EXTENSIONS than in an upgrade file aimed at end users, where it just
    looks scary and oblique.

    OK so I'll update that file tomorrow and reference it from the upgrade file.
    Any objections to that approach?

    - Steph


    ----- Original Message -----
    From: "Pierre" <pierre.php@gmail.com>
    To: "Steph Fox" <steph@zend.com>
    Cc: "Michael B Allen" <mba2000@ioplex.com>; <internals@lists.php.net>
    Sent: Thursday, September 14, 2006 8:14 PM
    Subject: Re: [PHP-DEV] Module API Changes

    Hello,
    On 9/14/06, Steph Fox wrote:
    OK, has anyone enough time to commit this please?

    I left the extension API change out of it though (the ME_* support) -
    does
    that really need to go in there too?
    This thread justifies the addition (and all other about the same topic :).
  • Pierre at Sep 14, 2006 at 6:30 pm
    Hello,
    On 9/14/06, Steph Fox wrote:
    Huh?

    The question was about module API change, which is transparent to anyone
    mixing and matching PHP and module versions (which incidentally they
    shouldn't be doing in the first place). The extension API doesn't matter to
    anyone but extension authors...
    Which are the target audience for this text, maybe I was not clear :)

    README.EXTENSIONS than in an upgrade file aimed at end users, where it just
    looks scary and oblique.

    OK so I'll update that file tomorrow and reference it from the upgrade file.
    Any objections to that approach?
    As long as there is a notice in the 5.2 ugprade me, I'm fine with
    that. Something like "internal API changed, see...".

    Thanks :)

    --Pierre
  • Steph Fox at Sep 14, 2006 at 6:36 pm
    Pierre,
    The question was about module API change, which is transparent to anyone
    mixing and matching PHP and module versions (which incidentally they
    shouldn't be doing in the first place). The extension API doesn't matter
    to
    anyone but extension authors...
    Which are the target audience for this text, maybe I was not clear :)
    Not at all. The upgrade guide explains the impact of the more important NEWS
    file changes at user level, and workarounds where necessary.
    As long as there is a notice in the 5.2 ugprade me, I'm fine with
    that. Something like "internal API changed, see...".
    Yep - cool. Hold off that commit then :)

    - Steph
  • Pierre at Sep 14, 2006 at 6:38 pm
    Hello,
    On 9/14/06, Steph Fox wrote:

    Not at all. The upgrade guide explains the impact of the more important NEWS
    file changes at user level, and workarounds where necessary.
    The target audience for *THIS* additon.
    As long as there is a notice in the 5.2 ugprade me, I'm fine with
    that. Something like "internal API changed, see...".
    Yep - cool. Hold off that commit then :)
    :)
  • Philip Olson at Sep 14, 2006 at 6:44 pm

    Erm, no they aren't in the upgrade guide, because the upgrade
    guide is aimed
    at user issues and this was seen primarily as an extension author
    issue. Do
    people generally think the module and extension API bumps should
    be in
    there?
    Rasmus was talking about the internals change and ask if they can be
    put in this file. I think it is a very good suggestion and no, I did
    not have the time (and will not in the next 10 days) to do it :)
    And a FYI, the documentation team has decided to create migration
    pages for minor releases of PHP and will use these README files as a
    base for this documentation. Before only major versions were
    documented this way. All should feel free to contribute to these
    docs :-)

    Regards,
    Philip
  • Michael B Allen at Sep 14, 2006 at 6:31 pm

    On Thu, 14 Sep 2006 19:25:49 +0200 "Steph Fox" wrote:

    Hi Michael, Pierre -

    Erm, no they aren't in the upgrade guide, because the upgrade guide is aimed
    at user issues and this was seen primarily as an extension author issue. Do
    people generally think the module and extension API bumps should be in
    there?
    I fine with looking at the source but it would be nice if there was a
    url WebCVS or somewhere to get a quick answer.

    Otherwise the only thing I really care about is that the minor number be
    incremented whenever ZEND_MODULE_API_NO changes. Obviously the installer
    needs that to pick the right module to install based on phpversion().

    Mike

    --
    Michael B Allen
    PHP Active Directory SSO
    http://www.ioplex.com/
  • Steph Fox at Sep 14, 2006 at 6:34 pm
    Hi Michael,
    Otherwise the only thing I really care about is that the minor number be
    incremented whenever ZEND_MODULE_API_NO changes. Obviously the installer
    needs that to pick the right module to install based on phpversion().
    Bug it? :)

    (against the installer I mean)
    Mike

    --
    Michael B Allen
    PHP Active Directory SSO
    http://www.ioplex.com/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedSep 14, '06 at 2:45p
activeSep 14, '06 at 6:44p
posts15
users4
websitephp.net

People

Translate

site design / logo © 2022 Grokbase