Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46233
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: <4B127C63.6060506@zend.com>
Date: Sun, 29 Nov 2009 15:51:31 +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> <4B127C03.1080707@zend.com>
In-Reply-To: <4B127C03.1080707@zend.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)

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 <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
>>
>>
>>   
>