[Pythonmac-SIG] macpython on future apple's intel processors?

[Ronald Oussoren]

On 7-jun-2005, at 22:45, Bob Ippolito wrote:

>
> On Jun 7, 2005, at 6:50 PM, Ronald Oussoren wrote:
>
>
>>
>> On 7-jun-2005, at 10:59, Bob Ippolito wrote:
>>
>>
>>
>>
>>>
>>> On Jun 7, 2005, at 12:36 AM, Markus Weissmann wrote:
>>>
>>>
>>>
>>>
>>>
>>>> I think this won't be a big headache for the Python community - not
>>>> even for
>>>> the whole open source people; in fact - as darwin for x86  
>>>> already is
>>>> available
>>>> for some time now - we've already tested some software on darwin/ 
>>>> x86.
>>>> You may find a list of RPMs I've built in end of 2004 for  
>>>> opendarwin
>>>> for Intel
>>>> here [1]. Just check for the py_* named packages and relax! :)
>>>>
>>>>
>>>>
>>>>
>>>
>>> That's totally not true, though.  Basically, almost NONE of the Mac-
>>> specific Python stuff works correctly on Mac OS X for Intel, and the
>>> changes required to fix that are hard.
>>>
>>>
>>>
>>
>> Maybe, maybe not. I've quite optimistic about PyObjC (except the  
>> inject part,
>> but that's because I'm not interested in that feature).
>>
>
> It's still a considerable amount of work to beat libffi into using  
> the sysv ABI with the exception or two that Apple has made, and  
> then get it to configure and compile BOTH ways at the same time.

Getting libffi to work on Intel was easy enough, the hard part was  
understanding the libffi code. Getting it to build a fat library will  
be harder. I'm thinking of ripping the entire autoconf layer out, and  
might in the long term even convert libffi to something that's more  
pyobjc specific. We're currently converting python arguments to  
libffi argument arrays and those are then converted to stack frames.  
The smells like an inefficient code path.

>
> Fixing mach_inject (in the homogenous architecture case) is MUCH  
> less work. and it should probably even be possible to make it work  
> for both PPC and Intel even if the injector and injectee  
> architecture differ... though that would be a fair amount of  
> additional work.

I looked at the mach_inject code in the hotel. It contained a lot  
less architecture-specific code than I had expected. I might even  
attempt a port to Intel this week. Cross-platform injection makes my  
head hurt :-)

>
>
>> The hard part will be the creation of fat binaries.
>>
>
> Yeah.

It shouldn't be too hard, libffi will probably be the hardest part.  
It should be possible to split the configure script into two parts:  
one that tests cpu features (sizeof(int), byte order, ...) and one  
that tests API features (do we have sockets, ...). The cpu-features  
part can be converted to something that uses feature macros instead  
of detection, e.g.

#if defined __i386__
#define LITTLE_ENDIAN
...
#elif defined __ppc__
#define BIG_ENDIAN
...
#elif ...
...

API features should be the same across architectures.

>
> BTW:  Nearly all bundlebuilder apps are broken on Mac OS X for  
> Intel, and all py2app apps work (via Rosetta, anyway).

Only the standalone ones work, --semi-standalone apps that use / 
System/Library/Frameworks/Python.framework will most likely not work  
(pyobjc for ppc in a python with an intel image).

Ronald