[SciPy-user] numpy 64 bit build on mac os x

Roger Herikstad roger.herikstad@gmail....
Tue May 19 22:52:39 CDT 2009

 I guess I rejoiced too soon. The build works in 64 bit mode, but if I
start the python interpreter in 32 bit mode, I get the following error
when I try to import numpy:

Python 2.6.2 (r262:71600, May 15 2009, 09:54:38)
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python64.framework/Versions/2.6/lib/python2.6/site-packages/numpy/__init__.py",
line 130, in <module>
    import add_newdocs
  File "/Library/Frameworks/Python64.framework/Versions/2.6/lib/python2.6/site-packages/numpy/add_newdocs.py",
line 9, in <module>
    from lib import add_newdoc
  File "/Library/Frameworks/Python64.framework/Versions/2.6/lib/python2.6/site-packages/numpy/lib/__init__.py",
line 4, in <module>
    from type_check import *
  File "/Library/Frameworks/Python64.framework/Versions/2.6/lib/python2.6/site-packages/numpy/lib/type_check.py",
line 8, in <module>
    import numpy.core.numeric as _nx
  File "/Library/Frameworks/Python64.framework/Versions/2.6/lib/python2.6/site-packages/numpy/core/__init__.py",
line 8, in <module>
    import numerictypes as nt
  File "/Library/Frameworks/Python64.framework/Versions/2.6/lib/python2.6/site-packages/numpy/core/numerictypes.py",
line 593, in <module>
    _typestr[key] = empty((1,),key).dtype.str[1:]
ValueError: array is too big.

Looking through the source, I find a reference to that error in the
file numpy/core/src/multiarray/ctors.c:1396 . From what I can
understand, this has something to do with the size of a pointer not
being what it is expected to be? Any thoughts on this?

~ Roger

On Wed, May 20, 2009 at 9:37 AM, Roger Herikstad
<roger.herikstad@gmail.com> wrote:
> Hi,
>  Just wanted to say thanks for looking into this. I now have a working
> 4-way universal build of numpy!
> ~ Roger
> On Wed, May 20, 2009 at 8:18 AM, David Warde-Farley <dwf@cs.toronto.edu> wrote:
>> On 16-May-09, at 3:23 AM, Roger Herikstad wrote:
>>> -Ibuild/src.macosx-10.5-universal-2.6/numpy/core/src/multia     rray
>>> -Ibuild/src.macosx-10.5-universal-2.6/numpy/core/src/umath -c'
>>> 1575 gcc: build/src.macosx-10.5-universal-2.6/numpy/core/src/
>>> _sortmodule.c
>>> 1576 In file included from numpy/core/include/numpy/ndarrayobject.h:
>>> 33,
>>> 1577                  from numpy/core/include/numpy/noprefix.h:7,
>>> 1578                  from numpy/core/src/_sortmodule.c.src:29:
>>> 1579 numpy/core/include/numpy/npy_endian.h:33:10: error: #error
>>> Unknown CPU: can not set endianness
>>> Is this an issue of the mixed endianness between ppc and intel macs?
>> Actually I discovered it's a small bug in npy_endian.h.
>> npy_cpu.h correctly detects and sets CPU architecture macros *but* for
>> some reason npy_endian.h doesn't handle PPC64 and set big-endian. So,
>> npy_cpu.h correctly detects PPC64 as the arch being built for but then
>> the endianness setting code doesn't know what to do with it. The AMD64
>> build works fine.
>> I've filed a ticket at http://projects.scipy.org/numpy/ticket/1111 and
>> attached a patch there, if you need it.
>> David
>> _______________________________________________
>> SciPy-user mailing list
>> SciPy-user@scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-user

More information about the SciPy-user mailing list