Building python packages for the correct architecture on OSX 10.5

["Martin v. Löwis"]

> 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