[PHP-DEV] php id string
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
Re: [PHP-DEV] php id string
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php id string
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php id string
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 d...@yandex.ru 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php id string
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 d...@yandex.ru 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php id string
On Sun, Nov 29, 2009 at 1:19 PM, Jess Portnoy j...@zend.com wrote: just displaying the gathered arch info I can see no harm in though... that's what we do. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php id string
Jess Portnoy j...@zend.com wrote in message news:4b1266e0.7010...@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 d...@yandex.ru 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php id string
Jess Portnoy j...@zend.com wrote in message news:4b125d15.4040...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php id string
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 j...@zend.com wrote in message news:4b1266e0.7010...@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 d...@yandex.ru 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php id string
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 j...@zend.com wrote in message news:4b1266e0.7010...@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 d...@yandex.ru 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php id string
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php id string
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SVN Account Request: volker
- development of php core - translations ( already had an account few years ago but stopped due to time issues ) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: volker
hi, Which account was it? Cheers, On Sun, Nov 29, 2009 at 7:33 PM, Volker Richter v...@vrmx.eu wrote: - development of php core - translations ( already had an account few years ago but stopped due to time issues ) -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: volker
hi it should be volker the corresponding email was vol...@php.net greetings, + volker hi, Which account was it? Cheers, On Sun, Nov 29, 2009 at 7:33 PM, Volker Richter v...@vrmx.eu wrote: - development of php core - translations ( already had an account few years ago but stopped due to time issues ) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Using a stream function into another module
Nobody can help me ? Is there someone who can just give me some astuces ? Regards, Samuel ROZE. 2009/11/27 Samuel ROZE samuel.r...@gmail.com: Hello, I want to use two stream functions (stream_array_to_fd_set and stream_array_from_fd_set) in a module (/etc/modulename/modulename.c). To use them, i included the streamsfuncs.h file, with: #include ext/standard/streamsfuncs.h The problem is that when I want to compile, i've these errors: /home/samuel/Développement/workspaces/C-Cpp/PHP_5_3/ext/sockets/sockets.c:877: undefined reference to `stream_array_to_fd_set' /home/samuel/Développement/workspaces/C-Cpp/PHP_5_3/ext/sockets/sockets.c:884: undefined reference to `stream_array_to_fd_set' /home/samuel/Développement/workspaces/C-Cpp/PHP_5_3/ext/sockets/sockets.c:891: undefined reference to `stream_array_to_fd_set' /home/samuel/Développement/workspaces/C-Cpp/PHP_5_3/ext/sockets/sockets.c:936: undefined reference to `stream_array_emulate_read_fd_set' /home/samuel/Développement/workspaces/C-Cpp/PHP_5_3/ext/sockets/sockets.c:957: undefined reference to `stream_array_from_fd_set' /home/samuel/Développement/workspaces/C-Cpp/PHP_5_3/ext/sockets/sockets.c:958: undefined reference to `stream_array_from_fd_set' /home/samuel/Développement/workspaces/C-Cpp/PHP_5_3/ext/sockets/sockets.c:959: undefined reference to `stream_array_from_fd_set' How can I do to use them into my module ? Regards, Samuel ROZE. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SVN Account Request: satoruyoshida (Re: [PHP-DOC] Can I get CVS account?)
# Cc'ed to internals list. Hi, Could you please give him the karma for phpdoc (or at least phpdoc/ja) ? On Mon, Nov 30, 2009 at 11:03 AM, Yoshida yosh...@zend.co.jp wrote: Hi, Masahiro-san. I feel very happy because I can meet with You also here ;-) I hope for satoruyoshida or syoshida as the account if possible. :D With King Wishes, Satoru Yoshida yosh...@zend.co.jp - Original Message - From: TAKAGI Masahiro tak...@php.net To: PHP Documentation ML php...@lists.php.net Cc: Yoshida yosh...@zend.co.jp Sent: Monday, November 30, 2009 10:40 AM Subject: Re: [PHP-DOC] Can I get CVS account? Hi, 2009/11/10 Yoshida yosh...@zend.co.jp: Hi, all. I will be happy if you would give me CVS account. I hope translation and correction on Japanese document of PHP. Thank you for joining us. But we are using not CVS but SVN now :-) I have participated in document translation of Zend Framework, too. And I play technical suppot at Zend Japan, ltd. If you want more detail from me, You could find in following :) https://www.ohloh.net/accounts/Satoru_Yoshida Yes. I know your translation skill and welcome your help. Could you please tell us the SVN account you want to use? Regards, -- TAKAGI Masahiro mailto:tak...@php.net -- TAKAGI Masahiro mailto:tak...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: SVN Account Request: satoruyoshida (Re: [PHP-DOC] Can I get CVS account?)
On Nov 29, 2009, at 6:17 PM, TAKAGI Masahiro wrote: # Cc'ed to internals list. Hi, Could you please give him the karma for phpdoc (or at least phpdoc/ja) ? Greetings Yoshida and all, I don't believe a SVN account request is on record, so please apply for one and it will be approved (with karma granted): - http://www.php.net/svn-php Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
