Hi,
% locate python | grep '\/python$\|\/python...$' | grep bin | xargs -I
% echo % -c "\"import numpy; print(numpy.__version__)\""
I am not sure what these two commands were supposed to return; I assume a
list of numpy versions. Something in the syntax goes wrong there. I tried a
number of different variations of brackets and quotes, but nothing
conclusive came out.
Sorry, I keep forgetting you use the C shell rather than bash. The
syntax is annoyingly different between the two. Instead try:
$ locate python | grep '\/python$\|\/python...$' | grep bin | xargs -I
% echo % -c '"import numpy ; print ( numpy.__version__ )"'
That should work better. I'm just glad you didn't decide to use the Korn
shell!
Anyways.
Importing numpy and scipy into the python version (/usr/local/bin/python)
is
indeed a problem. Here is certainly the reason why relax does not find
numpy. See below the ImportErrors.
(If I use my standard python, I have numpy...
[gre:~] paul% which python
python: aliased to
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python
[gre:~] paul% python
Python 2.7.5 (default, Jun 27 2013, 19:56:45)
[GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
This date is recent, but it cannot be the new official version you
installed in the last day. That one should have a date just before
the 15th of May, when it was released. Is this one self compiled? If
so, we might be able to set up that one to work with relax, if all
else fails.
[gre:~] paul% /usr/local/bin/python
Python 2.7.5 (v2.7.5:ab05e7dd2788, May 13 2013, 13:18:45)
Better :)
import numpy;print(numpy.__version__)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
[snip]
ImportError:
dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so,
2): no suitable image found. Did find:
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so:
no matching architecture in universal wrapper
This is quite a bizarre error. This is a clear architecture mismatch!
I'm reinstalling as I go here, and on my system I've tried both:
numpy-1.7.1-py2.7-python.org-
macosx10.6.dmg
(http://sourceforge.net/projects/numpy/files/NumPy/1.7.1/numpy-1.7.1-py2.7-python.org-macosx10.6.dmg/download)
numpy-1.7.1-py2.7-python.org-macosx10.3.dmg
(http://sourceforge.net/projects/numpy/files/NumPy/1.7.1/numpy-1.7.1-py2.7-python.org-macosx10.3.dmg/download)
This is Mac OS X 10.6.8. It boots into 32-bit mode. But I have
64-bit Python running. Both test numpy versions import fine on my
system. Maybe you need to try the other numpy version? And if that
doesn't work, then it will have to be compiled to get the correct
architecture!
import wx; print(wx.__version__)
2.9.4.0
This looks good! wxPython is the most difficult part to set up, normally.
Now I could either use a different version of python for relax (I guess you
would not recommend), or place numpy into the right path. I should rather
try the latter.
For this Python version, numpy is horribly broken. Try the other
numpy DMG version and, if that fails, we compile
http://sourceforge.net/projects/numpy/files/NumPy/1.7.1/numpy-1.7.1.tar.gz/download
with:
$ cd numpy-1.7.1.tar.gz
$ /usr/local/bin/python setup.py install
The same with scipy.
Hopefully one of these will work. Oh, also make sue that the Python
version printed out matches the DMG file you recently downloaded
exactly, just in case /usr/local/bin/python is a symbolic link to a
different Python version :S Maybe also type:
% ls -alh /usr/local/bin/python
and make sure that the date on that symlink is less than a day old,
and that it points to
/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7.
This seems to be ok:
[gre026248:~] paul% ls -alh /usr/local/bin/python
lrwxr-xr-x 1 root wheel 68B 8 Aug 22:52 /usr/local/bin/python ->
../../../Library/Frameworks/Python.framework/Versions/2.7/bin/python
That date looks good. The date that Python gives also looks good.
However, the fact that the owner is root may be a problem.
Unfortunately, a chown does not solve the issue:
No, that should be the case. Changing to a user is a security
problem. It is world executable, so the owner being root is
reasonable.
[gre:/Users/paul] root# chown paul /usr/local/bin/python
[gre:/Users/paul] root# ls -alh /usr/local/bin/python
lrwxr-xr-x 1 root wheel 68B 8 Aug 22:52 /usr/local/bin/python ->
../../../Library/Frameworks/Python.framework/Versions/2.7/bin/python
Hehe, your Mac stopped you from doing that :P
I still hesitate to compile numpy from source.
I might do so, though, especially if nothing else works.
Like I said above, try the other numpy DMG file, and if not, compile.
Numpy is straight forward. Scipy is more difficult and may require:
$ PATH=/usr/local/bin/:$PATH C_INCLUDE_PATH=/sw/include/suitesparse/
~/bin/python2.7 setup.py install
You'll have to find where suitesparse is installed on your system and
then point to the correct directory.
Regards,
Edward