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@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion