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