On Sep 17, 2006, at 6:53 PM, Martin v. Löwis wrote:

Ronald Oussoren schrieb:
One problem is that python's configure script detects the sizes of
various types and those values will be different on 32-bit and 64-bit
flavours.

FWIW, the PC build "solves" this problem by providing a hand-crafted
pyconfig.h file, instead of using an autoconf-generated one.
That could work for OSX as well, although it is tedious to keep
the hand-crafted file up-to-date.

For the PC, this isn't really a problem, since Windows doesn't suddenly
grow new features, at least not those that configure checks for. So
forking pyconfig.h once and then customizing it for universal binaries
might work.

Another approach would be to override architecture-specific defines.
For example, a block

#ifdef __APPLE__
#include "pyosx.h"
#endif

Thats what I had started on before Bob came up with the endianness check that is in pyconfig.h.in at the moment. I'd to do this instead of manually maintaining a fork of pyconfig.h, my guess it is a lot less likely that pyconfig.h will grow new size related macros than new feature related ones.

One possible issue here is that distutils has an API for fetching definitions from pyconfig.h, code that uses this to detect architecture features could cause problems.


could be added to the end of pyconfig.h, and then pyosx.h would have

#undef SIZEOF_LONG

#if defined(__i386__) || defined(__ppc__)
#define SIZEOF_LONG 4
#elif defined(__amd64__) || defined(__ppc64__)
#define SIZEOF_LONG 8
#else
#error unsupported architecture
#endif

Out of curiosity: how do the current universal binaries deal with this
issue?

The sizes of basic types are the same on PPC32 and x86 which helps a lot. The byteorder is different, but we can use GCC feature checks there. The relevant bit of pyconfig.h.in:

#ifdef __BIG_ENDIAN__
#define WORDS_BIGENDIAN 1
#else
#ifndef __LITTLE_ENDIAN__
#undef WORDS_BIGENDIAN
#endif
#endif

Users of pyconfig.h will see the correct definition of WORDS_BIGENDIAN regardless of the architecture that was used to create the file.

One of the announced features of osx 10.5 is 64-bit support throughout the system and I definitely want to see if we can get 4- way universal support on such systems. As I don't have a system that is capable of running 64-bit code I'm not going to worry too much about this right now :-)

Ronald

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
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

Reply via email to