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
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 ofphpinfo(). 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
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 Portnoyjvlad 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 ofphpinfo(). 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 whatphpinfo()shows
in Architecture, to the id string? Are there any reasons not to do this?-jvlad
"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 Portnoyjvlad 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 ofphpinfo(). 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 whatphpinfo()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
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,
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 ofphpinfo(). 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
--
--
Pierre
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,
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 ofphpinfo(). 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
just displaying the gathered arch info I can see no harm in though...
that's what we do.
Cheers,
Pierre
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
"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 PortnoyPierre 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,
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 ofphpinfo(). 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,
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
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 PortnoyPierre 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,
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 ofphpinfo(). 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,
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
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 Portnoyjvlad 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 PortnoyPierre 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,
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 ofphpinfo(). 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,
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" 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
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 PortnoyJess,
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
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