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
