[Numpy-discussion] I must be wrong? -- endian detection failure on Mac OSX 10.5

[Dustin Lang]

Hi,

I don't really believe this is a numpy bug that hasn't been detected, so 
it must be something weird about my setup, but I can't figure it out. 
Here goes.

The symptom is that while numpy-1.4.1 builds fine, numpy-1.5.0 and later 
releases fail with:

In file included from numpy/core/src/npymath/npy_math.c.src:56:
numpy/core/src/npymath/npy_math_private.h:78: error: conflicting types for ieee_double_shape_type
numpy/core/src/npymath/npy_math_private.h:64: note: previous declaration of ieee_double_shape_type was here
error: Command "gcc -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes 
-Inumpy/core/include 
-Ibuild/src.macosx-10.5-i386-2.7/numpy/core/include/numpy 
-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core 
-Inumpy/core/src/npymath -Inumpy/core/src/multiarray 
-Inumpy/core/src/umath -Inumpy/core/include 
-I/usr/local/python-2.7.2/include/python2.7 
-Ibuild/src.macosx-10.5-i386-2.7/numpy/core/src/multiarray 
-Ibuild/src.macosx-10.5-i386-2.7/numpy/core/src/umath -c 
build/src.macosx-10.5-i386-2.7/numpy/core/src/npymath/npy_math.c -o 
build/temp.macosx-10.5-i386-2.7/build/src.macosx-10.5-i386-2.7/numpy/core/src/npymath/npy_math.o" 
failed with exit status 1


The relevant code looks like,

#define IEEE_WORD_ORDER NPY_BYTE_ORDER

#if IEEE_WORD_ORDER == NPY_BIG_ENDIAN
// declare ieee_double_shape_type;
#endif

#if IEEE_WORD_ORDER == NPY_LITTLE_ENDIAN
// declare ieee_double_shape_type;
#endif


so it looks like both word-order blocks are getting compiled.

For the record, including the same header files as the failing code and 
compiling with the same command-line args I get:

LITTLE_ENDIAN is defined: 1234
__LITTLE_ENDIAN is not defined
__LITTLE_ENDIAN__ is defined: 1   (by gcc)
BIG_ENDIAN is defined: 4321
__BIG_ENDIAN is not defined
__BIG_ENDIAN__ is not defined
BYTE_ORDER is defined: 1234
__BYTE_ORDER is not defined
__BYTE_ORDER__ is not defined
NPY_BYTE_ORDER is defined
   => __BYTE_ORDER
NPY_BIG_ENDIAN is defined
   => __BIG_ENDIAN
NPY_LITTLE_ENDIAN is defined
   => __LITTLE_ENDIAN

and NPY_BYTE_ORDER etc are set in npy_endian.h, in this block of code:

#ifdef NPY_HAVE_ENDIAN_H
     /* Use endian.h if available */
     #include <endian.h>

     #define NPY_BYTE_ORDER __BYTE_ORDER
     #define NPY_LITTLE_ENDIAN __LITTLE_ENDIAN
     #define NPY_BIG_ENDIAN __BIG_ENDIAN
#else

(setup.py detected that I do have endian.h:
build/src.macosx-10.5-i386-2.7/numpy/core/include/numpy/_numpyconfig.h:#define NPY_HAVE_ENDIAN_H 1
)

So my guess is that npy_endian.h is expecting glibc-style endian.h with 
__BYTE_ORDER but getting Apple's endian.h with BYTE_ORDER.  Then 
NPY_BYTE_ORDER gets defined to __BYTE_ORDER which is itself not defined. 
Same with NPY_{BIG,LITTLE}_ENDIAN, and then apparently the two undefined 
things compare equal in wacky preprocessor land?


For what it's worth, in my own codebase I see that I do this:

#if \
   (defined(__BYTE_ORDER) && (__BYTE_ORDER == __BIG_ENDIAN)) || \
   (defined( _BYTE_ORDER) && ( _BYTE_ORDER ==  _BIG_ENDIAN)) || \
   (defined(  BYTE_ORDER) && (  BYTE_ORDER ==   BIG_ENDIAN))
// yup, big-endian
#endif


This is a Mac OSX 10.5.8 machine, MacBook5,1, Intel Core2 Duo CPU P8600 @ 
2.40GHz, gcc 4.4.6 and python 2.7.2

The weirdness on this system is that I installed a gcc with only x86_64 
support, while the kernel and uname insist that it's i386, but I don't 
*think* that's implicated here.


cheers,
dustin