[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.
-bob
More information about the Python-Dev
mailing list