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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
