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

[Samuel John]

Hi!

Your Machine should be able to handle at least Mac OS X10.6 and even 10.7.
If there is not a strong reason to remain on 10.5...

10.5 is so long ago, I can barely remember.

cheers,
 Samuel

On 01.02.2012, at 18:03, Dustin Lang wrote:

> 
> 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
> 
> 
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion