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

Bob Ippolito bob at redivi.com
Sat Mar 18 02:52:22 CET 2006

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.


More information about the Python-Dev mailing list