> This means the modules need to be compiles for at least both i386 and
> x86_64 in my case.
Building Python in 64-bit mode as a universal (fat) binary is not
supported in Python 2.5, period. So any solution you come necessarily
has to be a work-around.
The only solution I can see is to make a plain, non-fat installation
of Python in 64-bit mode, and then use that installation to build
64-bit extension modules.
> def Extension(*args, **kwargs):
> extra_args = ['-arch', 'ppc', '-arch', 'ppc64',
> '-arch', 'i386', '-arch', 'x86_64 ']
This cannot really work, for two reasons:
a) even if your extension module becomes x86_64 with that mechanism,
the Python interpreter itself (i.e. the Python framework) will be
purely 32-bit code. So it should not link correctly.
b) During configure, Python generates a pyconfig.h which has the
computed sizes of data types (such as int, long, size_t). It only
has a single such file, and the file is generated only during
configure. Therefore, the data in it cannot work both for 32-bit
and 64-bit architectures. When you compile for a 64-bit target
using the 32-bit pyconfig.h, the code may work incorrectly
(provided it makes use of the computed values somewhere) (*)
(*) It is surprising that pyconfig.h actually works for both
big-endian (ppc) and little-endian (i386) systems, even though
it computes the endianness during configure only once. This is
due to an OSX-specific hack in pyconfig.h, which hides the
definition of the computed endianness value, and uses the
value that the compiler provides as a macro instead.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
