[Numpy-discussion] Numpy on Mac OS X python 2.6

David Cournapeau cournapeau@cslab.kecl.ntt.co...
Tue Nov 25 01:19:40 CST 2008


On Mon, 2008-11-24 at 22:06 -0700, Charles R Harris wrote:
>         
> 
> Well, it may not be that easy to figure.  The (generated)
> pyconfig-32.h has
> 
> /* Define to 1 if your processor stores words with the most
> significant byte
>     first (like Motorola and SPARC, unlike Intel and VAX). 
> 
>     The block below does compile-time checking for endianness on
> platforms
>     that use GCC and therefore allows compiling fat binaries on OSX by
> using 
>     '-arch ppc -arch i386' as the compile flags. The phrasing was
> choosen
>     such that the configure-result is used on systems that don't use
> GCC.
>   */
> #ifdef __BIG_ENDIAN__
> #define WORDS_BIGENDIAN 1
> #else
> #ifndef __LITTLE_ENDIAN__
> /* #undef WORDS_BIGENDIAN */
> #endif
> #endif
>  

Hm, interesting: just by grepping, I do have WORDS_BIGENDIAN defined to
1 on *both* python 2.5 and python 2.6 on Mac OS X (running Intel).
Looking closer, I do have the above code (conditional) in 2.5, but not
in 2.6: it is inconditionally defined to BIGENDIAN on 2.6 !! That's
actually part of something I have wondered for quite some time about fat
binaries: how do you handle config headers, since they are generated
only once for every fat binary, but they should really be generated for
each arch.

> And I guess that __BIG_ENDIAN__  is a compiler flag, it isn't in any
> of the include files. In any case, this looks like a Python bug or the
> Python folks have switched their API on us.

Hm, actually, it is a bug in numpy as much as in python: python should
NOT include any config.h in their public namespace, and we should not
rely on it.

But with this info, it should be relatively easy to fix (by setting the
correct endianness by ourselves with some detection code)

David




More information about the Numpy-discussion mailing list