[Python-Dev] Problem with module loading on multi-arch?

[Bob Ippolito]

On Mar 17, 2006, at 4:38 PM, Neal Becker wrote:

> "Martin v. Löwis" wrote:
>
>> Neal Becker wrote:
>>> Sorry, maybe I used confusing terminology.
>>>
>>> A reference is here: http://fedoraproject.org/wiki/Packaging/Python
>>> This is the current setup.  For example, this is a standard macro  
>>> used by
>>> Redhat in RPM SPEC files for python:
>>>
>>> %define python_sitearch %(%{__python} -c "from  
>>> distutils.sysconfig import
>>> get_python_lib; print get_python_lib(1)")}
>>>
>>> %define python_sitelib %(%{__python} -c "from distutils.sysconfig  
>>> import
>>> get_python_lib; print get_python_lib()")}
>>>
>>> Clearly this practice is widespread.  It would seem that module  
>>> search
>>> needs some modification to fully support it.
>>
>> Ah. That isn't supported at all, at the moment. Redhat should not be
>> using it. Instead, there shouldn't be a difference between  
>> sitearch and
>> sitelib.
>>
>
> x86_64 is multiarch.  That means, we allow both i386 and x86_64  
> binaries to
> coexits.  Is the proposal that python should not support this?   
> That would
> be unfortunate.
>
> I suspect is would not be that difficult to correctly support  
> multiarch
> platforms.  As it is, this usually works - but the example I gave  
> above
> shows where it seems to break.

All the difficult issues supporting multi-arch are going to be with  
distutils, not Python itself.

On OS X it isn't all that hard to support (beyond backwards  
compatibility issues) because you run gcc once with the right options  
and get a single universal binary as output.  It would be a lot more  
invasive if GCC had to be run multiple times and the products had to  
be put in different places.

-bob