Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46232
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.185 as permitted sender)
Message-ID: <4B127C03.1080707@zend.com>
Date: Sun, 29 Nov 2009 15:49:55 +0200
User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706)
MIME-Version: 1.0
To: jvlad <dmda@yandex.ru>
CC: internals@lists.php.net
References: <61.CB.44817.91D421B4@pb1.pair.com> <fe05d1540911290343u66f13088iddb8c34cfcf13fe7@mail.gmail.com> <4B1266E0.7010405@zend.com> <7D.E0.48013.AD9721B4@pb1.pair.com>
In-Reply-To: <7D.E0.48013.AD9721B4@pb1.pair.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] php id string
From: jess@zend.com (Jess Portnoy)

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 <dmda@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 
>
>
>
>