Grokbase › Groups › PHP › php-internals › November 2009
FAQ
Hi all,

Starting with version 5.3 php checks id string when it loads the extensions
to match its own one and it also shows this string in PHP Extension Build
line of phpinfo(). That's great. This line contains api#, threadsafe, and
compiler. So it's almost all important thigs to check and make sure that a
particular module is binary-compatible with php core. All things, except
just one, the CPU. It's known that Windows runs on many CPUs, Solaris runs
fine under sparc, sparc64, x86, and x86_64. Needless to mention linux and
*bsd systems (I guess they are running on everything). Why not to add what
phpinfo() shows in Architecture, to the id string? Are there any reasons not
to do this?

-jvlad

Search Discussions

  • Jess Portnoy at Nov 29, 2009 at 11:38 am ⇧
    Hello,

    Have you considered cases such as universal MAC/Darwin builds? The
    universal build method [used only by Apple but still, many PHP
    developers do run MAC] means you have several archs bundled together in
    the same binary, and, a binary built 2 ways [i386 and PPC or i386 and
    x86_64 or even 4 ways for that matter] can work on any of these archs.
    How do you suggest to handle that?

    May the source be with you,
    Best regards,
    Jess Portnoy



    jvlad wrote:
    Hi all,

    Starting with version 5.3 php checks id string when it loads the extensions
    to match its own one and it also shows this string in PHP Extension Build
    line of phpinfo(). That's great. This line contains api#, threadsafe, and
    compiler. So it's almost all important thigs to check and make sure that a
    particular module is binary-compatible with php core. All things, except
    just one, the CPU. It's known that Windows runs on many CPUs, Solaris runs
    fine under sparc, sparc64, x86, and x86_64. Needless to mention linux and
    *bsd systems (I guess they are running on everything). Why not to add what
    phpinfo() shows in Architecture, to the id string? Are there any reasons not
    to do this?

    -jvlad


  • Jess Portnoy at Nov 29, 2009 at 11:41 am ⇧
    And, though I'm sure everyone on the list is capable of finding this URL
    on their own, a short explanation:
    http://en.wikipedia.org/wiki/Universal_binary

    May the source be with you,
    Best regards,
    Jess Portnoy



    Jess Portnoy wrote:
    Hello,

    Have you considered cases such as universal MAC/Darwin builds? The
    universal build method [used only by Apple but still, many PHP
    developers do run MAC] means you have several archs bundled together
    in the same binary, and, a binary built 2 ways [i386 and PPC or i386
    and x86_64 or even 4 ways for that matter] can work on any of these
    archs. How do you suggest to handle that?

    May the source be with you,
    Best regards,
    Jess Portnoy



    jvlad wrote:
    Hi all,

    Starting with version 5.3 php checks id string when it loads the
    extensions to match its own one and it also shows this string in PHP
    Extension Build line of phpinfo(). That's great. This line contains
    api#, threadsafe, and compiler. So it's almost all important thigs to
    check and make sure that a particular module is binary-compatible
    with php core. All things, except just one, the CPU. It's known that
    Windows runs on many CPUs, Solaris runs fine under sparc, sparc64,
    x86, and x86_64. Needless to mention linux and *bsd systems (I guess
    they are running on everything). Why not to add what phpinfo() shows
    in Architecture, to the id string? Are there any reasons not to do this?

    -jvlad


  • Jvlad at Nov 29, 2009 at 1:44 pm ⇧
    "Jess Portnoy" <jess@zend.com> wrote in message
    news:4B125D15.4040308@zend.com...
    Hello,

    Have you considered cases such as universal MAC/Darwin builds? The
    universal build method [used only by Apple but still, many PHP developers
    do run MAC] means you have several archs bundled together in the same
    binary, and, a binary built 2 ways [i386 and PPC or i386 and x86_64 or
    even 4 ways for that matter] can work on any of these archs. How do you
    suggest to handle that?

    May the source be with you,
    Best regards,
    Jess Portnoy



    jvlad wrote:
    Hi all,

    Starting with version 5.3 php checks id string when it loads the
    extensions to match its own one and it also shows this string in PHP
    Extension Build line of phpinfo(). That's great. This line contains api#,
    threadsafe, and compiler. So it's almost all important thigs to check and
    make sure that a particular module is binary-compatible with php core.
    All things, except just one, the CPU. It's known that Windows runs on
    many CPUs, Solaris runs fine under sparc, sparc64, x86, and x86_64.
    Needless to mention linux and *bsd systems (I guess they are running on
    everything). Why not to add what phpinfo() shows in Architecture, to the
    id string? Are there any reasons not to do this?

    -jvlad

    Jess,
    I'm not sure that people who compile php under MAC will do unitversal
    binaries.
    At least by-default gcc does not produce them and seems an extra tool is
    required.
    Finally, if you have 4 binaries in one file, why don't you have 4 id-strings
    for them?

    -jvlad
  • Pierre Joye at Nov 29, 2009 at 11:43 am ⇧
    hi,

    This info is available in phpinfo on windows and I would like to add
    it in the "php -v" output as well. I'm not sure how we can safely rely
    on this info on other platforms but that's definitively something we
    should try to do.

    Cheers,
    On Sun, Nov 29, 2009 at 11:29 AM, jvlad wrote:
    Hi all,

    Starting with version 5.3 php checks id string when it loads the extensions
    to match its own one and it also shows this string in PHP Extension Build
    line of phpinfo(). That's great. This line contains api#, threadsafe, and
    compiler. So it's almost all important thigs to check and make sure that a
    particular module is binary-compatible with php core. All things, except
    just one, the CPU. It's known that Windows runs on many CPUs, Solaris runs
    fine under sparc, sparc64, x86, and x86_64. Needless to mention linux and
    *bsd systems (I guess they are running on everything). Why not to add what
    phpinfo() shows in Architecture, to the id string? Are there any reasons not
    to do this?

    -jvlad



    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Pierre

    http://blog.thepimp.net | http://www.libgd.org
  • Jess Portnoy at Nov 29, 2009 at 12:19 pm ⇧
    Perhaps it would be wise to display both the build arch and the current
    arch on which its running?
    I used the Darwin/MAC universal build example before but even on Windows
    and *nix as well when you think about it, one can run a 32bit binary on
    a 64bit OS, usually provided the stack below [Apache, etc] is also 32 bit.
    So, unlike the PHP_COMPILER_ID check, which makes sense as the various
    VCs are declared as not quite compatible, I think in the case of
    different archs this would be a mistake, just displaying the gathered
    arch info I can see no harm in though...

    May the source be with you,
    Best regards,
    Jess Portnoy



    Pierre Joye wrote:
    hi,

    This info is available in phpinfo on windows and I would like to add
    it in the "php -v" output as well. I'm not sure how we can safely rely
    on this info on other platforms but that's definitively something we
    should try to do.

    Cheers,
    On Sun, Nov 29, 2009 at 11:29 AM, jvlad wrote:

    Hi all,

    Starting with version 5.3 php checks id string when it loads the extensions
    to match its own one and it also shows this string in PHP Extension Build
    line of phpinfo(). That's great. This line contains api#, threadsafe, and
    compiler. So it's almost all important thigs to check and make sure that a
    particular module is binary-compatible with php core. All things, except
    just one, the CPU. It's known that Windows runs on many CPUs, Solaris runs
    fine under sparc, sparc64, x86, and x86_64. Needless to mention linux and
    *bsd systems (I guess they are running on everything). Why not to add what
    phpinfo() shows in Architecture, to the id string? Are there any reasons not
    to do this?

    -jvlad



    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


  • Pierre Joye at Nov 29, 2009 at 12:29 pm ⇧

    On Sun, Nov 29, 2009 at 1:19 PM, Jess Portnoy wrote:

    just displaying the gathered arch info I can see no harm in though...
    that's what we do.

    Cheers,
  • Jvlad at Nov 29, 2009 at 1:57 pm ⇧

    just displaying the gathered arch info I can see no harm in though...
    that's what we do.
    hmm, 32bit php binary v5.3.1 under W7-64bit displays
    Windows NT MyHostName 6.1 build 7600 ((null)) i586

    If I needed to know current system, I'd prefer to see
    SYSTEMNAME,VERSION,HOST,CPU
    for example:
    Windows Seven,6.1.0.7600,MyHostName,x86_64

    and btw, it should be clear that Architecture is compile-time thing,
    not run-time, so there is one more reason to move it to id-string.



    -jvlad
  • Jvlad at Nov 29, 2009 at 1:40 pm ⇧
    "Jess Portnoy" <jess@zend.com> wrote in message
    news:4B1266E0.7010405@zend.com...
    Perhaps it would be wise to display both the build arch and the current
    arch on which its running?
    I used the Darwin/MAC universal build example before but even on Windows
    and *nix as well when you think about it, one can run a 32bit binary on a
    64bit OS, usually provided the stack below [Apache, etc] is also 32 bit.
    So, unlike the PHP_COMPILER_ID check, which makes sense as the various VCs
    are declared as not quite compatible, I think in the case of different
    archs this would be a mistake, just displaying the gathered arch info I
    can see no harm in though...

    May the source be with you,
    Best regards,
    Jess Portnoy



    Pierre Joye wrote:
    hi,

    This info is available in phpinfo on windows and I would like to add
    it in the "php -v" output as well. I'm not sure how we can safely rely
    on this info on other platforms but that's definitively something we
    should try to do.

    Cheers,
    On Sun, Nov 29, 2009 at 11:29 AM, jvlad wrote:

    Hi all,

    Starting with version 5.3 php checks id string when it loads the
    extensions
    to match its own one and it also shows this string in PHP Extension
    Build
    line of phpinfo(). That's great. This line contains api#, threadsafe,
    and
    compiler. So it's almost all important thigs to check and make sure that
    a
    particular module is binary-compatible with php core. All things, except
    just one, the CPU. It's known that Windows runs on many CPUs, Solaris
    runs
    fine under sparc, sparc64, x86, and x86_64. Needless to mention linux
    and
    *bsd systems (I guess they are running on everything). Why not to add
    what
    phpinfo() shows in Architecture, to the id string? Are there any reasons
    not
    to do this?

    -jvlad



    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php

    Jess,

    Current platform plays no role. If it can't run a particular php build,
    there is nothing to care of.
    What I do care of is ABA which depends on the compile-time arch and nothing
    else.
    It's my understanding that id-string is a part of the technology to make
    sure that extensions
    are compatible with core.

    -jvlad
  • Jess Portnoy at Nov 29, 2009 at 1:50 pm ⇧
    Apple ships their MAC OS with GCC that is capable of building universal
    binaries.
    Most MAC users expect packages to be built universal. Trust me, I also
    hate it but its true...
    If what you want is just to ensure the extensions are built for the same
    architecture as the PHP core, this I can understand, I'm just saying you
    need to take multiple archs bundled together under consideration. Also,
    I don't know if deciding for the dynamic loader if something can be
    loaded is so wise, if it can great, if not, it will yell at you anyhow..

    May the source be with you,
    Best regards,
    Jess Portnoy



    jvlad wrote:
    "Jess Portnoy" <jess@zend.com> wrote in message
    news:4B1266E0.7010405@zend.com...
    Perhaps it would be wise to display both the build arch and the current
    arch on which its running?
    I used the Darwin/MAC universal build example before but even on Windows
    and *nix as well when you think about it, one can run a 32bit binary on a
    64bit OS, usually provided the stack below [Apache, etc] is also 32 bit.
    So, unlike the PHP_COMPILER_ID check, which makes sense as the various VCs
    are declared as not quite compatible, I think in the case of different
    archs this would be a mistake, just displaying the gathered arch info I
    can see no harm in though...

    May the source be with you,
    Best regards,
    Jess Portnoy



    Pierre Joye wrote:
    hi,

    This info is available in phpinfo on windows and I would like to add
    it in the "php -v" output as well. I'm not sure how we can safely rely
    on this info on other platforms but that's definitively something we
    should try to do.

    Cheers,
    On Sun, Nov 29, 2009 at 11:29 AM, jvlad wrote:

    Hi all,

    Starting with version 5.3 php checks id string when it loads the
    extensions
    to match its own one and it also shows this string in PHP Extension
    Build
    line of phpinfo(). That's great. This line contains api#, threadsafe,
    and
    compiler. So it's almost all important thigs to check and make sure that
    a
    particular module is binary-compatible with php core. All things, except
    just one, the CPU. It's known that Windows runs on many CPUs, Solaris
    runs
    fine under sparc, sparc64, x86, and x86_64. Needless to mention linux
    and
    *bsd systems (I guess they are running on everything). Why not to add
    what
    phpinfo() shows in Architecture, to the id string? Are there any reasons
    not
    to do this?

    -jvlad



    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    Jess,

    Current platform plays no role. If it can't run a particular php build,
    there is nothing to care of.
    What I do care of is ABA which depends on the compile-time arch and nothing
    else.
    It's my understanding that id-string is a part of the technology to make
    sure that extensions
    are compatible with core.

    -jvlad


  • Jess Portnoy at Nov 29, 2009 at 1:51 pm ⇧
    BTW, Macports also support building PHP in universal mode.

    May the source be with you,
    Best regards,
    Jess Portnoy



    Jess Portnoy wrote:
    Apple ships their MAC OS with GCC that is capable of building
    universal binaries.
    Most MAC users expect packages to be built universal. Trust me, I also
    hate it but its true...
    If what you want is just to ensure the extensions are built for the
    same architecture as the PHP core, this I can understand, I'm just
    saying you need to take multiple archs bundled together under
    consideration. Also, I don't know if deciding for the dynamic loader
    if something can be loaded is so wise, if it can great, if not, it
    will yell at you anyhow..

    May the source be with you,
    Best regards,
    Jess Portnoy



    jvlad wrote:
    "Jess Portnoy" <jess@zend.com> wrote in message
    news:4B1266E0.7010405@zend.com...
    Perhaps it would be wise to display both the build arch and the
    current arch on which its running?
    I used the Darwin/MAC universal build example before but even on
    Windows and *nix as well when you think about it, one can run a
    32bit binary on a 64bit OS, usually provided the stack below
    [Apache, etc] is also 32 bit.
    So, unlike the PHP_COMPILER_ID check, which makes sense as the
    various VCs are declared as not quite compatible, I think in the
    case of different archs this would be a mistake, just displaying the
    gathered arch info I can see no harm in though...

    May the source be with you,
    Best regards,
    Jess Portnoy



    Pierre Joye wrote:
    hi,

    This info is available in phpinfo on windows and I would like to add
    it in the "php -v" output as well. I'm not sure how we can safely rely
    on this info on other platforms but that's definitively something we
    should try to do.

    Cheers,
    On Sun, Nov 29, 2009 at 11:29 AM, jvlad wrote:

    Hi all,

    Starting with version 5.3 php checks id string when it loads the
    extensions
    to match its own one and it also shows this string in PHP
    Extension Build
    line of phpinfo(). That's great. This line contains api#,
    threadsafe, and
    compiler. So it's almost all important thigs to check and make
    sure that a
    particular module is binary-compatible with php core. All things,
    except
    just one, the CPU. It's known that Windows runs on many CPUs,
    Solaris runs
    fine under sparc, sparc64, x86, and x86_64. Needless to mention
    linux and
    *bsd systems (I guess they are running on everything). Why not to
    add what
    phpinfo() shows in Architecture, to the id string? Are there any
    reasons not
    to do this?

    -jvlad



    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    Jess,

    Current platform plays no role. If it can't run a particular php
    build, there is nothing to care of.
    What I do care of is ABA which depends on the compile-time arch and
    nothing else.
    It's my understanding that id-string is a part of the technology to
    make sure that extensions
    are compatible with core.

    -jvlad

  • Jvlad at Nov 29, 2009 at 2:23 pm ⇧
    "Jess Portnoy" <jess@zend.com> wrote in message
    news:4B127C03.1080707@zend.com...
    Apple ships their MAC OS with GCC that is capable of building universal
    binaries.
    Most MAC users expect packages to be built universal. Trust me, I also
    hate it but its true...
    If what you want is just to ensure the extensions are built for the same
    architecture as the PHP core, this I can understand, I'm just saying you
    need to take multiple archs bundled together under consideration. Also, I
    don't know if deciding for the dynamic loader if something can be loaded
    is so wise, if it can great, if not, it will yell at you anyhow..

    May the source be with you,
    Best regards,
    Jess Portnoy
    Jess,
    Honestly, I see no problem with universal binaries. After all
    they are not that "universal" at all.
    Perhaps you missed another reply where I asked - if you have
    4 binaries in one file, why don't you have 4 id strings for them?

    and yes, many companies that provide their php extensions in pre-compiled
    form like Zend, ionCube, and
    many others are interested in a clear way on how to detect whether installed
    php is supported and
    what module among hunderd others to pick and install. So, you usee it's not
    a way to dictate
    the loader what to load. It's a way for installer to be wise enough.

    -jvlad
  • Jess Portnoy at Nov 29, 2009 at 2:43 pm ⇧
    Hi,

    Please see below.

    May the source be with you,
    Best regards,
    Jess Portnoy



    jvlad wrote:
    "Jess Portnoy" <jess@zend.com> wrote in message
    news:4B127C03.1080707@zend.com...
    Apple ships their MAC OS with GCC that is capable of building universal
    binaries.
    Most MAC users expect packages to be built universal. Trust me, I also
    hate it but its true...
    If what you want is just to ensure the extensions are built for the same
    architecture as the PHP core, this I can understand, I'm just saying you
    need to take multiple archs bundled together under consideration. Also, I
    don't know if deciding for the dynamic loader if something can be loaded
    is so wise, if it can great, if not, it will yell at you anyhow..

    May the source be with you,
    Best regards,
    Jess Portnoy
    Jess,
    Honestly, I see no problem with universal binaries. After all
    they are not that "universal" at all.
    Perhaps you missed another reply where I asked - if you have
    4 binaries in one file, why don't you have 4 id strings for them?
    The problem I see [and it can certainly be that we just don't understand
    each other's intentions :)], is this:
    If the PHP Core [the Apache module, CLI/CGI binary, etc] is built for
    instance as a 4 way universal binary [32bit and 64bit, Intel and PPC],
    the machine itself is, lets say, a 64bit Intel machine and the extension
    being examined is built 2 ways, say, 32bit and 64bit, how do you suggest
    we compare them?
    I mean, the extension should be able to load fine even though its just 2
    way because we are NOT running PPC here..
    and yes, many companies that provide their php extensions in pre-compiled
    form like Zend, ionCube, and
    many others are interested in a clear way on how to detect whether installed
    php is supported and
    what module among hunderd others to pick and install. So, you usee it's not
    a way to dictate
    the loader what to load. It's a way for installer to be wise enough.
    The installer really has nothing to do here the way I see it, a person
    may later take an extension built by some other party, this extension
    which technically could load just fine, will be rejected due the Engine
    test, as is the situation today when compiling the extension with a VC
    version different than core was compiled with. If you're just talking
    about warning [not the case these days with the compiler ID check, then
    perhaps].
    -jvlad


  • Jvlad at Nov 29, 2009 at 3:46 pm ⇧

    Honestly, I see no problem with universal binaries. After all
    they are not that "universal" at all.
    Perhaps you missed another reply where I asked - if you have
    4 binaries in one file, why don't you have 4 id strings for them?
    The problem I see [and it can certainly be that we just don't understand
    each other's intentions :)], is this:
    If the PHP Core [the Apache module, CLI/CGI binary, etc] is built for
    instance as a 4 way universal binary [32bit and 64bit, Intel and PPC], the
    machine itself is, lets say, a 64bit Intel machine and the extension being
    examined is built 2 ways, say, 32bit and 64bit, how do you suggest we
    compare them?
    I mean, the extension should be able to load fine even though its just 2
    way because we are NOT running PPC here..
    Well, for your universal extension you have 4 ids. If you care of
    installers, they
    should know all 4 ids for the module and pick this module if any one of them
    matches. If you care of php core, it will see only the loaded id after the
    loader has
    made its decision and picked right part from the hamburger.
    and yes, many companies that provide their php extensions in pre-compiled
    form like Zend, ionCube, and
    many others are interested in a clear way on how to detect whether
    installed php is supported and
    what module among hunderd others to pick and install. So, you usee it's
    not a way to dictate
    the loader what to load. It's a way for installer to be wise enough.
    The installer really has nothing to do here the way I see it, a person may
    later take an extension built by some other party, this extension which
    technically could load just fine, will be rejected due the Engine test, as
    is the situation today when compiling the extension with a VC version
    different than core was compiled with.
    In fact, the IDs will be different in this case - vc6 and vc9 for visual
    studio 6 and
    2008 respectively. So, still no problems. ID clearly indicates whether an
    extension
    can be used with particular php core distribution. It's only necessary to
    add CPU :)

    -jvlad

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedNov 29, '09 at 10:29a
activeNov 29, '09 at 3:46p
posts14
users3
websitephp.net

3 users in discussion

Jess Portnoy: 6 posts Jvlad: 6 posts Pierre Joye: 2 posts

Content

People

Support

Translate

site design / logo © 2022 Grokbase