HJBlog > Building 64bit NumPy/SciPy/PyLab on Snow Leopard

Thu, Sep 3, 2009, 12:47am Building 64bit NumPy/SciPy/PyLab on Snow Leopard

(Last updated: Wed, Jun 23, 2010, 1:59am)

hat follows is my collection of notes about installing a full 64-bit stack of NumPy, SciPy, PyLab, and all that entails on a fresh Snow Leopard system. If it helps out someone else trying to do something similar that would be great. If you look through what I've done and find things that could have been done better or in a more correct way, let me know. We will be building most things needed from source.

After trial and error, and plenty of the latter, I have streamlined the process down to installing the following, in order: gfortran, FFTW, UMFPACK, NumPy, SciPy and finally matplotlib (which includes PyLab).

Note: There used to be a great resource for this kinda thing, the Scipy Superpack page, but it appears now to be down, but hopefully not out. Until such a day, there is this page.

Please read the forums if you have any questions, disagree with something that I'm doing or just want to hear the fine things others have figured out. Those who have posted have important contributions and it's a great way to help others if you have some gem to contribute.

0. Setup

As of the last update of this article, I am using a clean installation of Snow Leopard, Mac OS X version 10.6.2, with developer tools installed, Xcode version 3.2.1.

I'm assuming MacPorts is not set up on your system yet, or at least I'm not making any use of it. If it is there, make sure your PATH environment variable doesn't have /opt/… listed before the other PATH directories or it may grab something from there when you don't want it to. (As with everything here, if you know better, by all means do what you know is best.) I use a tcsh environment, but the only difference here with my bash brethren will be in typing "export X=whatever" where I type "setenv X whatever".

Note: Things I didn't do… I'm sure there are lots of options that I should have turned on if I were savvy at all this stuff, but I did not include any instructions to build this stuff with Qt, VTK, or a lot of other neat stuff. So the fun interactive examples in matplotlib do not work with this. If someone wants to clue me in to the easiest way to make this happen, I'll be happy to add it to this tutorial. Also, some things like the wx libraries are disabled in this article, as they are still i386/ppc only in Snow Leopard, so if you want those you'll have to check into what that takes.

Also, a warning… While what is built below is indeed a full 32/64-bit stack, however, so far, 32-bit libraries will not work with it. For reasons that seem to be out of my hands, something isn't yet all dual-binary compatible and is only working in 64-bit mode. So if you need 32-bit compatibility, usually because of 32-bit modules you need to use, perhaps wait until a proper solution, here or elsewhere, is found.

The boxes below that show yellow text are meant to show what was is to be typed by you. It does not show any of the crazy text that gets spit back out at you when you type it. Be sure to type in one line, let it do its thing, then type in the next. Do not just copy and paste a multi-line block of these commands unless you know what you're doing.

The boxes with light blue text are meant to show lines inside a text file that are to be edited by you at the appropriate time.

For this tutorial, I'm going to build everything in a fresh ~/tmp directory (I'll assume nothing else is in there too), so open up a fresh Terminal window, make it nice and wide, and, if it doesn't already exist, warm up your fingers with a simple command:

mkdir ~/tmp

1. gfortran

This is the simplest step, merely downloading and installing the 4.2.3 version of gfortran listed on this page of tools for use with R. While the gfortran binary itself is i386/ppc, it does create i386/x8664 binaries just fine.

Update: There is also a gfortran build 4.2 specifically for Snow Leopard under the "Alternative and experimental tools" section, if you'd rather use that. It's built against Snow Leopard's gcc 4.2 for Xcode 3.2, which in principle is a better match than the older 4.2.3 version. While it seems to work fine, as of this writing, gfortran-42-5646.pkg for Snow Leopard contains gfortran version 4.2.1, not 4.2.4 as labelled. Also, if you already installed another gfortran, this one is placed in /usr/bin, not /usr/local/bin, for some reason, so make sure that your $PATH is discovering the gfortran version you want to use before proceeding. (Quick check: see what "which gfortran" responds with at the Terminal after installing.)

As an aside, to have gfortran build a 64-bit binary, pass it the flag "-m64". To create a universal 32/64-bit binary, you can take an i386 and an x8664 binary and create one universal with lipo: lipo -create bin32 bin64 -output binUniversal.

(On one machine I downloaded and installed gfortran 4.5.0 from source found on the GNU site, but for reasons I can't remember now, switched back to this one. I'm not sure if there's a reason to avoid the 4.5.0 version.)

I'm assuming /usr/local/bin is in everyone's path, but if you type echo $PATH and don't see it included, type this in (or the bash equivalent):
setenv PATH "${PATH}:/usr/local:/usr/local/bin"

2. FFTW — a discrete Fourier transform library

This is just a straight-forward download and build, using the binary from the official FFTW site.

rehash
cd ~/tmp
curl -O http://www.fftw.org/fftw-3.2.2.tar.gz
tar xf fftw-3.2.2.tar.gz
cd fftw-3.2.2
./configure CC="gcc -arch i386 -arch x8664" CXX="g++ -arch i386 -arch x8664" CPP="gcc -E" CXXCPP="g++ -E"
make
sudo make install

3. UMFPACK — routines for solving unsymmetric sparse linear systems

How much fun would it be if everything were just as smooth as those two steps? UMFPACK requires being built along side AMD and UFconfig , where all 3 sources are located in the same parent directory. All of them are available on the U of Florida CISE site if you want to poke around there for other versions or whatnot.
cd ~/tmp
curl -O http://www.cise.ufl.edu/research/sparse/umfpack/current/UMFPACK.tar.gz
curl -O http://www.cise.ufl.edu/research/sparse/UFconfig/current/UFconfig.tar.gz
curl -O http://www.cise.ufl.edu/research/sparse/amd/current/AMD.tar.gz
tar xf AMD.tar.gz
tar xf UFconfig.tar.gz
tar xf UMFPACK.tar.gz

What follows comes from both the sparse docs in the projects and some helpful notes from Tony S Yu.

In your editor of choice, edit the file UFconfig/UFconfig.mk and make two changes. On line 51, change the F77 setting to read
F77 = gfortran

and then starting around line 295, un-comment the lines related to the Mac setup to look as follows:
#------------------------------------------------------------------------------
# Macintosh
#------------------------------------------------------------------------------

CC = gcc
CFLAGS = -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664
LIB = -lstdc++
BLAS = -framework Accelerate
LAPACK = -framework Accelerate

Now we copy some header files and then make the UMFPACK:
cp UFconfig/UFconfig.h AMD/Include/
cp UFconfig/UFconfig.h UMFPACK/Include/
cd UMFPACK
make
make hb
make clean

The make hb line is in just there to make sure it doesn't break, and the make clean is just to keep the place tidy.

4. NumPy — Numeric Python .

Apple includes NumPy in a standard Snow Leopard install, and it's already 32/64-bit. Very nice and all, but it won't build against the SciPy source that I'll be using in the next step, so we need to build a fresh NumPy and to have it used instead of Apple's. We can tell Python to use our own by setting the search path appropriately.

For the next steps I set the environmental variables to build against 32 and 64bit architectures. If you open a new Terminal window or start a new shell for some reason in between these steps, be sure to reinstate these environmental variables:
setenv MACOSXDEPLOYMENTTARGET 10.6
setenv CFLAGS "-arch i386 -arch x8664"
setenv FFLAGS "-m32 -m64"
setenv LDFLAGS "-Wall -undefined dynamiclookup -bundle -arch i386 -arch x8664"
setenv PYTHONPATH "/Library/Python/2.6/site-packages/"

which, in bash-speak, is just
export MACOSXDEPLOYMENTTARGET=10.6
export CFLAGS="-arch i386 -arch x8664"
export FFLAGS="-m32 -m64"
export LDFLAGS="-Wall -undefined dynamiclookup -bundle -arch i386 -arch x8664"
export PYTHONPATH="/Library/Python/2.6/site-packages/"

Ok, now we're ready to build NumPy. First grab the source (which may take a bit), then build away. You can either build this from the source repository, which is more cutting-edge, but more prone to getting cut of course, or grab the current stable source (the .tar.gz, not the Mac-specific file!). I'll show what to do for both cases.

First the sane stable-source way. You have to use a web browser and go to the Numpy SourceForge Project page, download the latest stable source (I went with, v1.3.0), then mv the downloaded file to ~/tmp (at least that's what I'm assuming here). Future readers may have to adjust the following to suit their actual downloaded source versions. ("Hello, people of the future!")
cd ~/tmp
tar xf numpy-1.3.0.tar
cd numpy-1.3.0

Or, for those wishing to use the latest source, (which has the fun feature of following all current updates as they happen):
cd ~/tmp
svn co http://svn.scipy.org/svn/numpy/trunk numpy
cd numpy

To make NumPy aware of where we put our AMD and UMFPACK source files, copy the default site.cfg.example file
cp site.cfg.example site.cfg

and modify the contents of site.cfg, around line 99, to read like the following:
[amd]
librarydirs = /Users/jeff/tmp/AMD/Lib
includedirs = /Users/jeff/tmp/AMD/Include
amdlibs = amd

[umfpack]
librarydirs = /Users/jeff/tmp/UMFPACK/Lib
includedirs = /Users/jeff/tmp/UMFPACK/Include
umfpacklibs = umfpack

Obviously, change the /Users/jeff/tmp part to wherever you ended up putting those files.

Continuing, whichever way you went with the source,
python setup.py build --fcompiler=gnu95
sudo python setup.py install

5. SciPy — Scientific Python

Unable to find a more correct way to do the following, I have found that the system's NumPy gets in the way of building SciPy, so I change its name, to prevent it from making mischief. This is an ugly and fragile solution, but I'm unable to find a workable correct solution to this problem. After you're done with the whole install, feel free to change the library name back, but I'm not sure if it ends up interfering in daily use. (Please contribute if you know the proper way to handle this! See the many forum comments below for discussions about other ways to handle this.)
sudo mv /System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/numpy \
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/numpyX

Stable-source-style: Grab the latest stable source from the SciPy SourceForge Project, then…
cd ~/tmp
tar xf scipy-0.7.1.tar
cd scipy-0.7.1
python setup.py build
sudo python setup.py install

and source-repository-style:
cd ~/tmp
svn co http://svn.scipy.org/svn/scipy/trunk scipy
cd scipy
python setup.py build
sudo python setup.py install

6. matplotlib — 2- and 3-d plotting libraries, w/ PyLab

Stable source, gotten from the matplotlib SourceForge page, and:
cd ~/tmp
tar xf matplotlib-0.99.1.1.tar
cd matplotlib-0.99.1.1

or grab the latest source:
cd ~/tmp
svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib matplotlib
cd matplotlib

and before we continue we need to first edit the file make.osx which is right in the directory you should be in now. Within the first few lines of the file you'll see something similar to what I have below, but not quite, so update it to include these changes:
MACOSXDEPLOYMENTTARGET=10.6

PREFIX=/usr/local

## You shouldn't need to configure past this point (and yet…)

PKGCONFIGPATH="${PREFIX}/lib/pkgconfig"
CFLAGS="-arch i386 -arch x8664 -I${PREFIX}/include -I${PREFIX}/include/freetype2 -isysroot /Developer/SDKs/MacOSX10.6.sdk"
LDFLAGS="-arch i386 -arch x8664 -L${PREFIX}/lib -syslibroot,/Developer/SDKs/MacOSX10.6.sdk"
FFLAGS="-arch i386 -arch x8664"

and, since Snow Leopard's wx libraries are a touch behind the times and are compiled i386/ppc, edit line 57 (or thereabouts) of the file setup.cfg to comment out the following line:
wxagg = False

from here we can finally build matplotlib with the next, and final, two commands:
sudo make -f make.osx fetch deps mplbuild mplinstall
sudo python setup.py install

7. iPython — interactive computing environment

David, below, made the fine point of including the quick and easy steps to also pop iPython on your machine. You can check the download page to grab the latest source version, which for me was 0.10, and do as with the others above:
cd ~/tmp
curl -O http://ipython.scipy.org/dist/ipython-0.10.tar.gz
tar xf ipython-0.10.tar.gz
cd ipython-0.10
python setup.py build
sudo python setup.py install

and, voila, iPython, the more fun way to play with all of the above.

8. Done

You may now want to rename the system's NumPy back to what it was, allowing it to be updated nicely when system updates come along, and hopefully it doesn't stir up any troubles:
sudo mv /System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/numpyX \
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/numpy

However, if you do run into troubles, rename it back to numpyX. On my system, re-enabling the system's NumPy causes trouble, but not everyone seems to need it set up this way. Sorry I can't be of more help on this issue (yet).

Ok, you're done. Scram. Beat it. Get to codin'. Well, if you want to actually see if it's working (and I really hope it is at this point), try running any number of different examples listed on the matplotlib examples page. Again, many of them do not work when they require libraries such as Qt or VTK, but most of them should work as advertised.

Hope this was of help to someone, if only myself in the future when installing it on other machines. Of course, by then, there'll be some great one-click install that'll do it for me, or just be totally built-in to the system the way NumPy already is (well, a boy can dream).

RSS Comment Feed for this page

lup (Thu, September 3rd, 2009, 4:54pm UTC)

Thanks a lot, I was soooo bored of the "wrong architecture" messages in one library or the other going back and forth with the compiling… this is just perfect.
minor glitch: tar xzf *.gz was not "copy and paste working" so I had to unpack each separately:
tar xzf AMD.tar.gz
tar xzf UFconfig.tar.gz
tar xzf UMFPACK.tar.gz
are you sending this upstream to the dev teams of numpy + scipy + pylab?

Jeff (Thu, September 3rd, 2009, 10:35pm UTC)

Glad this helped you out, lup. Thanks for that correction, too! I admit that line was added in at the last minute without testing. (And it seems that tar doesn't need the z flag when using the x flag as well. Must've been a habit I picked up from years ago.)

I'll mention this article to the powers that be in scipy-land. I'm sure they'll know how to integrate these notes and have it handled properly.

David (Fri, September 4th, 2009, 1:47am UTC)

Thanks Jeff,
Just upgraded from Leopard to Snow and borked my "scientific" python environment. This sorted it out nicely.
A few small issues:
I had to run the build step for Scipy through sudo, I was getting fortran permission errors (but perhaps this is an issue with my fortran install).

Also, I uncommented and adjusted the PREFIX= line in make.osx (matplotlib install) otherwise it compiled freetype/png/etc in the / dir of my HDD and left them there.

For what its worth, IPython also installs easily following your instructions above.

Thanks again!

Jeff (Fri, September 4th, 2009, 2:19am UTC)

Good idea, David, to include the quick one-two for iPython at the end. I'll add that in.

Interesting about both the sudo for fortran and the PREFIX issues. Not sure why I got out of those tweaks, but this discussion can serve to archive such specific issues that others will surely run across as well.

David (Sun, September 6th, 2009, 8:24am UTC)

Jeff, don't know if you and others are having the same problem, but can't seem to import scipy.stats module with this setup — get failures from odepack and what seem to be BLAS/LAPACK problems.

Looks related to this:
http://www.shocksolution.com/2009/01/14/scipyintegrate-odepack-import-error-solved/

Wondering if SciPy doesn't like being compiled against the native Mac BLAS libraries from veclib?
Or maybe I have another fortran problem.
Have you had any troubles with this?
David.

Jack (Mon, September 7th, 2009, 11:28pm UTC)

Haven't really compiled scipy from source before, but after jumping headfirst into snow leopard and finding myself in deep trouble, I have to say, you've done a great job of getting me out of it!

Although, am I supposed to see a scary rash of compiler warnings? Seems like every other statement violates some convention. I didn't follow your instructions to the letter, though (played fast and loose with the fftw libs and other dependencies — maybe that's what's causing all the trouble).

Bryan Lunt (Tue, September 8th, 2009, 4:04pm UTC)

The MOST IMPORTANT THING!!!
It SHOULD BE #1 on the list!!!!
Make sure you don't have python.org or macpython, or other non-apple python distributions installed and overriding your Snow Leopard's default python installation.

Jeff (Tue, September 8th, 2009, 4:17pm UTC)

David, I haven't run into the problem you mention with stats on any of my 3 SL installs here, so not sure what might have gone wrong along the way. Even ran some stats code i found on the net to be sure.

Jack, A rash of scary compiler warnings: YES. Try to go into Zen state of some kind when they are flying by. I guess I got numb to them after a while and forgot to say anything about it. They seem to be ultimately harmless, at least for now.

Bryan, Thanks for mentioning that. Although I make the assumption way up there that people are using a clean SL install, it's more probable that people here have upgraded from a Leopard install and may have such things on their system.

Jack (Tue, September 8th, 2009, 6:55pm UTC)

Hey Jeff, I took the liberty of running

1 echo "import scipy
2 scipy.test('full')" | python > scipy-test-log 2>&1

and have the results uploaded here: http://dl.getdropbox.com/u/561535/scipy-test-log

The short version is,
1 Ran 4115 tests in 486.157s
2
3 FAILED (KNOWNFAIL=10, SKIP=32, errors=289)

But, uh, I'll just ignore that and use scipy as if nothing happened. Better something than nothing, right?

Jeff (Tue, September 8th, 2009, 11:56pm UTC)

Jack, After installing a fresh copy of nose, I gave the full test a go, which I hadn't done before, and compared with your results.

I noticed some differences in our setup:
- I don't get the deprecation warning you get about scipy.linsolve at the top.
- You are using the NumPy 1.2.1 installed on the system, but I'm using NumPy 1.4.0.dev7345 that I grabbed from recent source
- Your SciPy is 0.7.1, and I'm using 0.8.0.dev5911
- Our Python and nose versions are the same

I get the same clapack warning as you, but not the cblas warning you get. After this point in the test you get a million more warnings than I do.

I also get a zillion ERRORs related to the test suite that I'm looking into now. It'd be great to have a clean test, or something closer than this. Here's what I have currently:

1 Ran 4467 tests in 350.047s
2
3 FAILED (KNOWNFAIL=8, SKIP=32, errors=167, failures=24)

I'll update this if I have something substantial to contribute on this front.

Ben (Wed, September 9th, 2009, 7:25pm UTC)

hey guys,

thanks for this very usefull script,

I followed it till the end and works pretty well except pour the matplotlib part,

here is there error I got :
1 building 'matplotlib.backends.tkagg' extension
2 g++-4.2 -Wl,-F. -bundle -undefined dynamiclookup -arch i386 -arch ppc -arch x8664
3 build/temp.macosx-10.6-universal-2.6/src/aggpytransforms.o build/temp.macosx-10.6-universal-2.6/src/
4 tkagg.o build/temp.macosx-10.6-universal-2.6/CXX/cxxextensions.o build/temp.macosx-10.6-universal-2.6/
5 CXX/cxxsupport.o build/temp.macosx-10.6-universal-2.6/CXX/IndirectPythonInterface.o build/
6 temp.macosx-10.6-universal-2.6/CXX/cxxextensions.o -lstdc++ -lm -lfreetype -lz -lstdc++ -lm -o
7 build/lib.macosx-10.6-universal-2.6/matplotlib/backends/tkagg.so -framework Tcl -framework Tk
8 ld: library not found for -lfreetype
9 collect2: ld returned 1 exit status
10 ld: library not found for -lfreetype
11 collect2: ld returned 1 exit status
12 ld: library not found for -lfreetype
13 collect2: ld returned 1 exit status
14 lipo: can't open input file: /var/tmp//cc5GeY7r.out (No such file or directory)
15 error: command 'g++-4.2' failed with exit status 1
16 zsh: exit 1 sudo python setup.py install

any input on that ?

thanks

Ben (Thu, September 10th, 2009, 11:02am UTC)

I was just missing the freetype library.

if you have port installed just do:
1 sudo port install freetype

and that'll fix it

Hasan (Thu, September 10th, 2009, 10:49pm UTC)

You've mentioned:

While the gfortran binary itself is i386/ppc, it does create i386/x8664 binaries just fine.

What flag do I need to set to tell fortran to compile for x8664?
Doing gfortran -arch x86_64 results in

f951: error: unrecognized command line option "-arch"

Jeff (Thu, September 10th, 2009, 10:58pm UTC)

Hasan, I should have mentioned that the flag to give to gfortran is "-m64" (I'll add it to the post now).

Richard West (Sat, September 12th, 2009, 12:55am UTC)

Re: Hasan and Jeff

does that mean we should replace:

export FFLAGS="-arch i386 -arch x86_64"

with:

export FFLAGS="-m32 -m64"

or something like that?

Richard (Sat, September 12th, 2009, 12:55pm UTC)

Any succes trying something like this?
»> import scipy.integrate

I get a bunch of errors that your blog thinks is spam so I can only paste the summary:

ImportError: dlopen(/Library/Python/2.6/site-packages/scipy/special/cephes.so, 2): no suitable image found. Did find:
/Library/Python/2.6/site-packages/scipy/special/cephes.so: mach-o, but wrong architecture

Jeff (Sat, September 12th, 2009, 1:16pm UTC)

Richard, You have an architecture mismatch somewhere. Make sure that your builds are all both 32 and 64bit (or just the arch that you want it to all be). See what architectures are listed when you type "file /Library/Python/2.6/site-packages/scipy/special/_cephes.so" in the Terminal.

FWIW, from what I compiled from this article, I can get integrate to import and ran a few tests, which mostly work:
( ipython ) ✂
In [1]: from math import exp In [2]: from scipy.integrate import quad, inf In [3]: quad( lambda x: x**2, 0, 1 ) Out[3]: (0.33333333333333337, 3.7007434154171887e-15) In [4]: quad( lambda x: x**3/(exp(x)-1), 0.1, 10 ) Out[4]: (6.431600896801668, 6.1280828820706537e-09)
1 In [1]: from math import exp
2 In [2]: from scipy.integrate import quad, inf
3 In [3]: quad( lambda x: x**2, 0, 1 )
4 Out[3]: (0.33333333333333337, 3.7007434154171887e-15)
5 In [4]: quad( lambda x: x**3/(exp(x)-1), 0.1, 10 )
6 Out[4]: (6.431600896801668, 6.1280828820706537e-09)

but which also fail some of the SciPy Tutorial examples:
( ipython ) ✂
In [5]: from scipy.integrate import inf In [6]: quad(lambda x: x**3/(exp(x)-1), 0.1, inf)
1 In [5]: from scipy.integrate import inf
2 In [6]: quad(lambda x: x**3/(exp(x)-1), 0.1, inf)

fails with an "OverflowError: math range error", which is troubling, but I don't think it's a fault with the way scipy is setup here, though I might be mistaken.

Richard (Sat, September 12th, 2009, 4:41pm UTC)

Turns out I was using the gfortran 4.5.0 , which doesn't understand the "-arch i386 -arch x86_64" flags and uses the -m64 stuff you mention above.
When I use gfortran 4.2.3 from http://r.research.att.com/tools/ the instructions work.
Perhaps that is why you gave up on gfortran 4.5.0 in step 1.

Richard W (Sun, September 13th, 2009, 11:28am UTC)

Has anyone tried something like:
export VERSIONERPYTHONPREFER32BIT=yes
python -c 'import numpy'

It doesn't work for me — although we seemed to compile numpy as 32/64 bit, it won't actually work as 32 bit. A shame, as tons of my other modules don't (yet) work as 64-bit.

http://projects.scipy.org/numpy/ticket/1221

Sergei Vieira (Sun, September 13th, 2009, 11:16pm UTC)

When I type: ipython -pylab
I get the following message…
In summary…I am not able to run matplotlib
Where did I go wrong?
1 Leopard libedit detected.
2 ERROR: matplotlib could NOT be imported! Starting normal IPython.
3 Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51)
4 Type "copyright", "credits" or "license" for more information.
5
6 IPython 0.10 -- An enhanced Interactive Python.
7 ? -> Introduction and overview of IPython's features.
8 %quickref -> Quick reference.
9 help -> Python's own help system.
10 object? -> Details about 'object'. ?object also works, ?? prints more.

Srinath V (Mon, September 14th, 2009, 4:56pm UTC)

Thank you so much for putting this together. I have noticed that in the make.osx for matplotlib, the line:
CFLAGS="-Os -arch x86_64 -arch i386 -l${PREFIX}/include"

if cut&pasted puts a "-l" (capital ell) instead of an "-I" (capital eye). Thus, you may want to use a different font?

David Herrera (Mon, September 14th, 2009, 10:59pm UTC)

I couldn't run: sudo make -f make.osx fetch deps mplbuild mplinstall
1 checking for C compiler default output file name…
2 configure: error: C compiler cannot create executables
3 See `config.log' for more details.
4 make: *** [png] Error 77

perhaps because I didn't have a pkgconfig file in ~/dev/lib/
I tried to install pkgcong-0.23 thinking that would solve it, but it didn't
Instead, I manually installed the libpng and freetype2 libraries.
I couldn't run ./configure, instead I had to use sudo ./configure. Not sure if that was the problem with the make.osx script.

Looks like everything installed correctly. Let me know if you want to see the config.log file. I'll report any issues I find with my installation. Thanks

Andre Campos (Thu, September 17th, 2009, 8:15pm UTC)

My system was so unstable after this prodedures, that I decided to format and reinstall everything. I think I will wait for something less risky. Meanwhile I go on using Matlab. Its is not free software, but the opportunity cost is lower than losing precious time deciding whichflag to use in your gcc.

David (Fri, September 18th, 2009, 2:04am UTC)

Jeff,

My errors importing scipy.stats/scipy.integrate got sorted out. I had inadvertently used a different fortran version to compile parts of numpy and scipy and they just don't play well together. If anyone is having errors with these components, I would suggest fully removing all versions of fortran and then reinstalling only version 4.2.3 from r.research — as stated in the numpy install docs (and scipy also I think) they will fail with errors if you use the HP version or verson 4.5… You will then need to recompile numpy and scipy.

Also, as another minor thing, in the final part of step 3 you create a .numpy-site.cfg file in the home dir. This step is mainly required if you are going to use the easy_install tools. If you are compiling from source as you have detailed, you can simply put that information about [amd] and [umfpack] in the site.cfg file in your numpy source dir at the time of compiling.

Thanks again Jeff — great guide.

John (Sun, September 20th, 2009, 9:28am UTC)

Hi Jeff,

Like Ben above, all is well until the matplotlib make, which fails. This has happened on both upgraded and clean Snow Leopard installs, and I can't find a way around it. Editing out some of the long parts, the error I get is:
1 building 'matplotlib.ft2font' extension
2 gcc-4.2 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -Os -arch x8664 -arch i386 -I/include -pipe
3 -DPYARRAYAUNIQUESYMBOL=MPLARRAYAPI -I/Library/Python/2.6/site-packages/numpy/core/include -I.
4 -I/Library/Python/2.6/site-packages/numpy/core/include/freetype2 -I./freetype2
5 -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c src/ft2font.cpp
6 -o build/temp.macosx-10.6-universal-2.6/src/ft2font.o
7 cc1plus: warning: command line option "-Wstrict-prototypes" is valid for C/ObjC but not for C++
8 In file included from src/ft2font.h:13,
9 from src/ft2font.cpp:1:
10 /include/ft2build.h:56:38: error: freetype/config/ftheader.h: No such file or directory

…lots removed, happy to email…

src/ft2font.cpp:98: error: ‘FTInt’ was not declared in this scope
/Library/Python/2.6/site-packages/numpy/core/include/numpy/multiarrayapi.h:1174: warning: ‘int importarray()’ defined but not used
lipo: can't open input file: /var/tmp//ccoIauD8.out (No such file or directory)
error: command 'gcc-4.2' failed with exit status 1
make: *** [mplbuild] Error 1

Any advice would be life-saving (or at least sanity-saving) -- thanks!

john

Jeff (Tue, September 22nd, 2009, 1:17am UTC)

Sorry, I was out of town last week. I need to catch up with the comments. Quick notes:

1) I should mention above that my disabling of Apple's Numpy is potentially problematic down the road. 2) I will add notes about building from latest stable releases instead of from source (I'm perhaps a bit too playful with my local builds). 3) There was a #3, but I lost my train of thought. More later…

Jay (Wed, September 23rd, 2009, 7:24pm UTC)

Thanks man very helpful

Peter (Wed, September 23rd, 2009, 8:30pm UTC)

Thanks a lot! Very helpful.

Greg (Thu, September 24th, 2009, 11:41pm UTC)

I'm getting the same error message as John when I try to compile matplotlib.
1 ……
2 ……
3 src/ft2font.cpp:96: error: variable or field 'drawbitmap' declared void
4 src/ft2font.cpp:96: error: 'FTBitmap' was not declared in this scope
5 src/ft2font.cpp:96: error: 'bitmap' was not declared in this scope
6 src/ft2font.cpp:97: error: 'FTInt' was not declared in this scope
7 src/ft2font.cpp:98: error: 'FTInt' was not declared in this scope
8 /Library/Python/2.6/site-packages/numpy/core/include/numpy/multiarrayapi.h:1174: warning:
9 'int importarray()' defined but not used
10 lipo: can't figure out the architecture type of: /var/tmp//cciuW995.out
11 lipo: can't open input file: /var/tmp//cc1Lf2gd.out (No such file or directory)
12 error: command 'gcc-4.2' failed with exit status 1
13 make: *** [mplbuild] Error 1

Jean-Louis (Mon, September 28th, 2009, 3:30pm UTC)

Hi Jeff,

I must admit I did not follow your installation guide, but for something similar, I got stuck on an error that does not appear in the above comments… yet.

I got numpy and ipython installed, already. However, I fail to install matplotlib: I had the same problems to install the dependencies as David Herrera (see above comment). It so happens that my version (0.99.1.1) of the make.osx file did not use any flags for the dependencies: CFLAGSDEPS and LDFLAGSDEPS were never used… I used this instead, and it seemed to work:

CFLAGS="-arch i386 -arch x8664 -I${PREFIX}/include -I${PREFIX}/include/freetype2 -isysroot /Developer/SDKs/MacOSX10.6.sdk"
LDFLAGS="-arch i386 -arch x8664 -L${PREFIX}/lib -syslibroot,/Developer/SDKs/MacOSX10.6.sdk"

However, I get stuck with the "make mplbuild" step. Here s the error:

ImportError: /usr/local/lib/wxPython-unicode-2.8.10.1/lib/python2.6/site-packages/wx-2.8-mac-unicode/wx/core_.so: no appropriate 64-bit architecture (see "man python" for running in 32-bit mode)

I m not sure how to go around this, I tried to install wxPython from source, but that did not work out either (some strange problems at compilation). Anyway, has anyone already been confronted to that error?

cheers,

jean-louis

Jean-Louis (Mon, September 28th, 2009, 3:53pm UTC)

About my last post: I checked the file "setup.cfg" in the matplotlib directory. I commented the line
#wxagg = True

The compilation then went fine and I believe everything should be working fine, now.

I hope this piece of information may help some other people…

Cheers !

Jean-Louis

Conrad Huang (Tue, September 29th, 2009, 4:54pm UTC)

Hi, Jeff. Thanks for the tips. I only needed matplotlib and your instructions were just what I needed. The only issue I had was that a number of files ended up in / (eg /lib, /share, /include). Since these files were created in support for Python, I ended up adding to make.osx the line
PREFIX=python-config --prefix

and that put all the files into /System/Library/Frameworks/Python.framework/Versions/2.6, which was acceptable for my purposes.

Thanks again.

Conrad

PS For the folks who are seeing the "error: freetype/config/ftheader.h: No such file or directory" message, check your CFLAGS line to make sure you have the "-I${PREFIX}/include/freetype2" flag. That's what fixed it for me.

Lion (Tue, September 29th, 2009, 7:36pm UTC)

For those of you still having trouble to install matplotlib:

Change the beginning of make.osx to:

MACOSXDEPLOYMENTTARGET=10.6

## You shouldn't need to configure past this point

CFLAGS="-arch i386 -arch x8664 -I${PREFIX}/include -I${PREFIX}/include/freetyp$
LDFLAGS="-arch i386 -arch x8664 -L${PREFIX}/lib -syslibroot,/Developer/SDKs/Ma$
FFLAGS="-arch i386 -arch x8664"

and additionally as JeanLouis said:

About my last post: I checked the file "setup.cfg" in the matplotlib directory. I commented the line
#wxagg = True

and than keep following the instructions. Seems to have worked great for me :-)

Rock on!

Lion (Tue, September 29th, 2009, 7:38pm UTC)

I forgot:

I downloaded the stable matplotlib 0.99.1.1 and not the repository version and compiled it as written above. I did everything else as written in the article.

Just in case it makes a difference.

Jeff (Wed, September 30th, 2009, 3:20am UTC)

Ok, I have been reading all the comments and suggestions and have walked through the steps on a completely new fresh Snow Leopard system to try out some things, which I'll reflect in the article above.

4 tiny typos in the original article were corrected, including a bad flag being passed in the make.osx file (many thanks, Srinath). Hope these didn't trip people up too much.

As Bryan and David have pointed out, you may want to make sure that older or different installs of python / macpython and gfortran are out of the way or uninstalled before running through these install steps. (It may be as easy is changing the order of your $PATH variable to find the /usr/local copies before others in /opt or elsewhere.)

Tonight's fresh install was done using the latest stable source instead of the svn source, which is really what I should suggest for others to do. I sometimes frivolously live on the edge more than is practical, especially when writing a tutorial for others and I'll reflect this option above.

Jean_Louis, perhaps because I'm now building from stable source, I too found that I have to put in #wxagg = True" in order to get matplotlib to build, so I'll add that note in up there.

Also, I ended up changing my make.osx file settings to a hybrid of mine and the suggestions of Jean-Louis and Lion, although I don't have the energy tonight to figure out if the FFLAGS setting is needed or not (I'll have it in for now).

This is a great discussion!
Many thanks to everyone contributing both problems and solutions.

Nicholas Lundgaard (Thu, October 1st, 2009, 10:59am UTC)

Jeff, have you looked at the http://r.research.att.com/tools/ page lately? They've posted a gfortran package built for Snow Leopard, which is gfortran 4.2.4 (rather than the 4.2.3 in the article). This one is built against the Snow Leopard build of gcc 4.2; I am not sure if there's a realistic benefit to that. You'll find it under the "Alternative and experimental tools" section. I am starting to redo the process as I speak, using this one. Might be worth a mention in the article if it works.

Jeff (Thu, October 1st, 2009, 12:51pm UTC)

Thanks, Nicholas! I didn't realize they added that. I'll be sure to mention that in the article. Two tiny hiccups with it that I found so far: One is that it places it in /usr/bin instead of /usr/local/bin by default, so your $PATH may still grab an older gfortran install when building if not careful, and the other is that it appears to be gfortran 4.2.1, not 4.2.4 as labelled. It seems to work fine, however.

Nicholas Lundgaard (Thu, October 1st, 2009, 3:58pm UTC)

Jeff, I've been mucking around with getting things working anew, and after some strange issues with forgetting to set the PREFIX thing on matplotlib, I'm back to _cephes.so from scipy not being 64-bit and hosing the scipy installation.

On the 4.2.1 vs. 4.2.4 thing, I was also thrown by that when I poked through the installation. I think it says "4.2.1" with gfortran -v because it's built for Apple's gcc 4.2.1. The folders where the install files are put are also labelled as 4.2.1. I think it actually is 4.2.4 as the author claims, and that these oddities are because of the gcc version.

Still, I'd love to hear if you have more luck getting this gfortran working with all this; I'm worried that it's not doing something right, but at this point it's just as likely I haven't cleaned out my old build properly.

Jeff (Thu, October 1st, 2009, 4:18pm UTC)

Nicholas, I checked to make sure that my _cephes.so on my various machines all built 32/64-bit and they are. Perhaps check to make sure that your environment flags are set as with the Numpy section settings?

On gfortran, I'll trust the author that it's 4.2.4, especially since I have no idea what the difference is and he actually built it. =]

Nicholas Lundgaard (Thu, October 1st, 2009, 7:19pm UTC)

Jeff, Thanks. You're right, my problem was a weird error that was actually the result of me not paying careful attention when I built scipy. I cleaned it out and re-built it. It turns out that I got some "permission denied" errors when the build was accessing libamd.h… I copy the fortran stuff into /usr/local/lib and /usr/local/include, respectively (and adjust the references accordingly), but apparently somewhere in there Mac OS X saw fit to strip the header files down so that only the owner (root) had read permissions. added read permissions to the files, re-did it, and all is kosher--my problem was clearly unrelated to gfortran.

So it sounds like the Snow Leopard build of gfortran may be the safest route, compatibility-wise, though as you say it's too bad it installs into /usr rather than /usr/local.

SBates (Tue, October 6th, 2009, 9:32am UTC)

Thanks for the really helpful page!
When I try to install Matplotlib, I'm getting the following error:
1 REQUIRED DEPENDENCIES
2 numpy: 1.2.1
3 freetype2: found, but unknown version (no pkg-config)
4 * WARNING: Could not find 'freetype2' headers in any
5 * of '.', './freetype2'.

Now I'm not a newbie, but I am still only beginning to get comfortable with unix environments, so I may be missing something simple — but I have freetype installed from macports, plus there is a freetype-2.3.7 directory in my matplotlib directory. Should it be able to find the header files?!

thanks for any help you can offer.

Isabel (Wed, October 7th, 2009, 8:10am UTC)

Thanks very much for this page!
I have a trouble compiling the matplotlib part (the rest works pretty. I have followed the tutorial till the end).

Here is the error I got when I build matplotlib with the command: sudo make -f make.osx …

1 …
2 cc -arch i386 -arch x8664 -I/usr/local /include -I/usr/local /include/freetype2 -isysroot \
3 /Developer/SDKs/MacOSX10.6.sdk -DNOsnprintf -DHASsprintfvoid -DNOERRNOH -c -o adler32.o adler32.c
4 cc -arch i386 -arch x8664 -I/usr/local /include -I/usr/local /include/freetype2 -isysroot \
5 /Developer/SDKs/MacOSX10.6.sdk -DNOsnprintf -DHASsprintfvoid -DNOERRNOH -c -o compress.o compress.c
6 cc -arch i386 -arch x8664 -I/usr/local /include -I/usr/local /include/freetype2 -isysroot \
7 /Developer/SDKs/MacOSX10.6.sdk -DNOsnprintf -DHASsprintfvoid -DNOERRNOH -c -o crc32.o crc32.c
8 i686-apple-darwin10-gcc-4.2.1: /include: No such file or directory
9 i686-apple-darwin10-gcc-4.2.1: no input files
10 i686-apple-darwin10-gcc-4.2.1: /include: No such file or directory
11 i686-apple-darwin10-gcc-4.2.1: no input files
12 i686-apple-darwin10-gcc-4.2.1: /include: No such file or directory
13 i686-apple-darwin10-gcc-4.2.1: i686-apple-darwin10-gcc-4.2.1: /include: No such file or directory
14 …
15 i686-apple-darwin10-gcc-4.2.1: /include/freetype2: No such file or directory
16 …
17 lipo: can't figure out the architecture type of: /var/tmp//ccUaeA7c.out
18 …
19 make[1]: *** [compress.o] Error 1
20 …
21 make: *** [zlib] Error 2

any idea?

thanks

Michael (Thu, October 8th, 2009, 1:32pm UTC)

Isabel:

-I/usr/local /include should read -I/usr/local/include
You have an extra space in there.

Isabel (Tue, October 13th, 2009, 8:34am UTC)

Many thanks, Michael!
I've gone crazy trying to understand the meaning of the /include directory that appeared when compiling zlib. The problem was an extra space at the end of PREFIX variable in make.osx file. Now everything works perfectly.

Hunter (Wed, October 14th, 2009, 7:13pm UTC)

I'm following the instructions as closely as possible, and when I try to build scipy, I get the following:
1 (…stuff working…)
2 building extension "scipy.sparse.linalg.dsolve.ssuperlu" sources
3 building extension "scipy.sparse.linalg.dsolve.umfpack.umfpack" sources
4 adding 'scipy/sparse/linalg/dsolve/umfpack/umfpack.i' to sources.
5 swig: scipy/sparse/linalg/dsolve/umfpack/umfpack.i
6 swig -python -I/Users/Hunter/Documents/Devel/AMD/Include \
7 -o build/src.macosx-10.6-universal-2.6/scipy/sparse/linalg/dsolve/umfpack/umfpackwrap.c \
8 -outdir build/src.macosx-10.6-universal-2.6/scipy/sparse/linalg/dsolve/umfpack scipy/sparse/linalg/dsolve/umfpack/umfpack.i
9 scipy/sparse/linalg/dsolve/umfpack/umfpack.i:192: Error: Unable to find 'umfpack.h'
10 scipy/sparse/linalg/dsolve/umfpack/umfpack.i:193: Error: Unable to find 'umfpacksolve.h'
11 (…another ~15 similar errors…)
12 scipy/sparse/linalg/dsolve/umfpack/umfpack.i:272: Error: Unable to find 'umfpackgetnumeric.h'
13 error: command 'swig' failed with exit status 1

Any ideas?

Hunter (Wed, October 14th, 2009, 7:18pm UTC)

Sorry, I forgot to add, numpy builds and installs just fine. It even tests fine (better than the apple included numpy), which I was having trouble with in another context. Anyway, thanks so much for this resource and your time.

Hunter (Sat, October 17th, 2009, 1:43pm UTC)

Ok, I've tried a couple of other things, and still not getting it. Obviously, given the above error, swig can't find UMFPACK. All the UMFPACK*.h files are where they're supposed to be, in ~/Documents/Devel/UMFPACK/Include but for some reason that's not in the search path of swig. I tried
1 export CFLAGS="-arch i386 -arch x8664 -I/Users/Hunter/Documents/Devel/UMFPACK/Include"

and copying ~/.numpy-site.cfg to ~/.scipy-site.cfg, but neither of those worked. I checked earlier in the build output, and noticed this:
1 umfpackinfo:
2 amdinfo:
3 FOUND:
4 libraries = ['amd']
5 librarydirs = ['/Users/Hunter/Documents/Devel/AMD/Lib']
6 swigopts = ['-I/Users/Hunter/Documents/Devel/AMD/Include']
7 definemacros = [('SCIPYAMDH', None)]
8 includedirs = ['/Users/Hunter/Documents/Devel/AMD/Include']
9
10 FOUND:
11 libraries = ['umfpack', 'amd']
12 librarydirs = ['/Users/Hunter/Documents/Devel/UMFPACK/Lib', '/Users/Hunter/Documents/Devel/AMD/Lib']
13 swigopts = ['-I/Users/Hunter/Documents/Devel/AMD/Include']
14 definemacros = [('SCIPYAMDH', None)]
15 includedirs = ['/Users/Hunter/Documents/Devel/AMD/Include']

So, something's clearly not right here, but I have no idea how to fix it. Any help would be greatly appreciated.

Darren (Sun, October 18th, 2009, 1:14pm UTC)

instead of moving the default numpy installation in System/Frameworks, you can direct python to search first by adding the following to ~/.profile:

export PYTHONPATH=/Library/Python/2.6/site-packages:${PYTHONPATH}

Note, I just started using OS X yesterday, but I have had to work through this same issue with Ubuntu.

Darren (Sun, October 18th, 2009, 1:29pm UTC)

I forgot to add, you would also have to add a line to your sudoers file for that to work:

Defaults env_keep += "PYTHONPATH"

Pete (Sun, October 18th, 2009, 9:03pm UTC)

Hi All, having a different problem with matplotlib. When I run the build command I get

1 sudo make -f make.osx fetch deps mplbuild mplinstall
2 …
3 Checking for mmap support… No.
4 gcc -arch i386 -arch x8664 -I/usr/local/include -I/usr/local/include/freetype2 -isysroot \
5 /Developer/SDKs/MacOSX10.6u.sdk -DNOsnprintf -DHASsprintfvoid -DNOERRNOH -c -o adler32.o adler32.c
6 gcc -arch i386 -arch x8664 -I/usr/local/include -I/usr/local/include/freetype2 -isysroot \
7 /Developer/SDKs/MacOSX10.6u.sdk -DNOsnprintf -DHASsprintfvoid -DNOERRNOH -c -o compress.o compress.c
8 gcc -arch i386 -arch x8664 -I/usr/local/include -I/usr/local/include/freetype2 -isysroot \
9 /Developer/SDKs/MacOSX10.6u.sdk -DNOsnprintf -DHASsprintfvoid -DNOERRNOH -c -o crc32.o crc32.c
10 In file included from crc32.c:29:
11 zutil.h:21:24: error: stddef.h: No such file or directory
12 zutil.h:23:22: error: string.h: No such file or directory
13 zutil.h:24:22: error: stdlib.h: No such file or directory
14 crc32.c:36:24: error: limits.h: No such file or directory
15 In file included from crc32.c:29:
16 zutil.h:21:24: error: stddef.h: No such file or directory
17 zutil.h:23:22: error: string.h: No such file or directory
18 zutil.h:24:22: error: stdlib.h: No such file or directory
19 crc32.c:36:24: error: limits.h: No such file or directory
20 lipo: can't figure out the architecture type of: /var/tmp//ccc4ZzsB.out
21 make[1]: *** [crc32.o] Error 1
22 make[1]: *** Waiting for unfinished jobs….
23 make: *** [zlib] Error 2

It looks like a problem with gcc under root maybe? Did anyone else run into this??

Jeff (Sun, October 18th, 2009, 10:06pm UTC)

I have a spare drive that I test on, so tonight I created a completely clean install of 10.6.1 with the basic Xcode dev tools and then carefully walked through this guide, along with the many fine comments from the discussion. I made many minor changes to the tutorial but nothing major. I also wanted to check on problems others were having.

It is worth mentioning that I added a line at the end to change the name of Apple's Numpy back to what it was, since I only needed it out of the way while compiling, and I did notice that some system updates have indeed altered that library since. Sorry about any inconveniences I've caused anyone on that. Here is the code I used to right the wrong post Apple's update (only do this if you notice that you have both a "numpy" and a "numpyAPPLEDEFAULT" directory in /System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python, and check to see if it looks like this as well:

It turns out that nothing different exists in those new folders and files at all, but for some reason the system push around files, no doubt confused by my renaming in the original version of this tutorial. (Important: If you don't know what I'm talking about, ignore the following.) Here's a set of commands to clean things up: (pardon the riskiness factor here…)
sudo rm -r /System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/numpy
sudo rm -r /System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/numpyAPPLEDEFAULT/core
sudo rm -r /System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/numpyAPPLEDEFAULT/distutils
sudo rm -r /System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/numpyAPPLEDEFAULT/f2py
sudo rm -r /System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/numpyAPPLEDEFAULT/numarray
sudo rm -r /System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/numpyAPPLEDEFAULT/random
sudo mv /System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/numpyAPPLEDEFAULT/numpyAPPLEDEFAULT \
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/numpy
sudo rmdir /System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/numpyAPPLEDEFAULT

I'm still looking into issues that others are having.

Pete (Sun, October 18th, 2009, 10:10pm UTC)

My fault -- typo in the SDK names above 10.6u -> 10.6

Jeff (Sun, October 18th, 2009, 10:28pm UTC)

Darren, when I did tonight's build I did try your PYTHONPATH setting, but when building scipy, it steadfastly went straight to the Numpy in the System folder. I'm sure there's some simple place in the Python config files that allows me to set the priorities straight.

Hunter (Mon, October 19th, 2009, 1:28pm UTC)

Well, I finally fixed my problem! I traced the error back to where the installer was setting those unfpackinfo and amdinfo dictionaries, and modified the source of the relevant .py file by adding two lines telling it where umfpack was. Probably not the nicest solution, and I still don't know what caused the problem in the first place, but it worked for me.

Darren (Tue, October 20th, 2009, 9:48am UTC)

Jeff,

Did you remember to "source ~/.profile", and to add PYTHONPATH to the list of environment variables to keep in sudoers?

Darren (Tue, October 20th, 2009, 10:24am UTC)

Here is a note from http://www.python.org/download/mac:

"Python comes pre-installed on Mac OS X, but due to Apple's release cycle, it's often one or even two years old. The overwhelming recommendation of the "MacPython" community is to upgrade your Python by downloading and installing a newer version from the Python standard release page."

This would solve the problem of numpy-1.2.1 being imported, because the new python won't pick up the system python packages. Too bad they didn't mention the all important qualifier that the mac installer disk image was not compiled to support x86_64.

Ross Coleman (Tue, October 20th, 2009, 2:06pm UTC)

I think there's a much simpler way to install matplotlib from source. I'm not using scipy, so I'm using the numpy that Apple bundled with the OS. I don't know if this will work when you build your own numpy, but I would think so.

I made no changes to make.osx

I successfully compiled and installed matplotlib 0.99.0 from source as follows:

Change to setupext.py: (to find freetype2 that Apple bundled with the OS)
basedir = {
…
'darwin' : ['/Developer/SDKs/MacOS10.6.sdk/usr/X11/', …],
…
}

1 $python setup.py build
2 $sudo python setup.py install

@Darren: Apple includes Python 2.6 in Snow Leopard, and numpy doesn't support Python 3.x yet, so I don't see much of a reason to install your own Python.

Darren (Tue, October 20th, 2009, 4:27pm UTC)

basedir = {
…
'darwin' : ['/Developer/SDKs/MacOS10.6.sdk/usr/X11/', …],
…
}

Could you be a bit more explicit? What did you put in place of "…" in the list?

Darren (Tue, October 20th, 2009, 4:40pm UTC)

This appears to have worked for me, note it is MacOSX10.6.sdk, not MacOS10.6.sdk
basedir = {
…
'darwin' : ['/Developer/SDKs/MacOS10.6.sdk/usr/X11/',],
…
}

Niall (Fri, October 23rd, 2009, 6:51am UTC)

Matplotlab causing python to crash. Built following instructions on snow leopard using svn versions. When I try to import matplotlib.pyplot python crashes with

»> import matplotlib.pyplot
python(25582) malloc: *** error for object 0x10181f820: pointer being freed was not allocated
*** set a breakpoint in mallocerrorbreak to debug
Abort trap

Any help would be greatly appreciated.

Xavier (Sat, October 24th, 2009, 3:09pm UTC)

Hi,

I do not see my comments appearing. However, I tried a matplotlib install following Ross Coleman's comment. And everything works fine.

Thks again for that very useful page,
Cheers,
X.

Hunter (Wed, October 28th, 2009, 10:54am UTC)

This page has been incredibly helpful, but I wonder if the author would be willing to add a section (or a whole new post!) on adding a 64-bit, Cocoa-enabled, Python-enabled VTK to this stack… I'm still wrestling with it (after having gotten most everything else up and running) and though I've seen several other walkthroughs around the net, none are as awesome as this.

Jonny (Thu, October 29th, 2009, 4:55am UTC)

Thanks very much for taking the time to write all this out, it has been very helpful.

It would be really handy if you and Darren could confirm a definitive answer for how to deal with this issue of moving numpy aside. I have run into problems with this where I have compiled my own C modules against the newly-installed numpy 1.3.0, but at runtime it is the OS version of numpy that is loaded. This produces an instant and hard-to-diagnose crash in importarray(). At the moment I am just sticking with your original suggestion of renaming the OS version of numpy and not renaming it back. I'm not entirely clear what negative consequences this will have — does the confusion during software update actually do any harm?

As an aside I am not sure why the code in importarray is not spotting this problem at runtime. This checks NPYVERSION compatibility between the headers and the loaded module. A comment in ndarrayobject.h states:
Some changes, such as adding a function pointer to the end of the
function table, can be made without breaking binary compatibility.
In this case, only the NPYFEATUREVERSION (*not* NPYVERSION)
would be increased
Unfortunately in this case importarray, which is defined in the header file multiarrayapi.h makes use of one of those new function pointers (PyArray_GetEndianness), and since this function pointer is missing a crash occurs. It strikes me that this is a bug in numpy, but I don't know enough about how this is all meant to work to be sure…

Darren (Sat, October 31st, 2009, 11:07am UTC)

I think renaming the system numpy is not a very good long-term solution. I imagine that if the system numpy is updated in the future, the updated version will reappear on the PYTHONPATH and once again take precedence over the user-installed version.

Just a reminder, I direct python to search first my locally installed packages before the system packages by adding the following to ~/.profile:

export PYTHONPATH=/Library/Python/2.6/site-packages:${PYTHONPATH}

And in order for that PYTHONPATH to be respected when I use sudo to install something like svn scipy, which will not build using the system numpy, I added a line to my sudoers file (use visudo to edit it):

Defaults env_keep += "PYTHONPATH"

It would be so much easier to install a local 64-bit macpython framework from python.org, if such a thing existed. Anyone know if one will be available for python-2.7?

IsoOctane (Sun, November 1st, 2009, 10:07am UTC)

Thanks for the guide, in the end though I ended up doing this:

- Installed 64-bit python 2.6.4 from sources, doing a framework install (./configure --enable-framework)

- Added the python binary directory to the path BEFORE the system python locations

- Installed latest numpy, scipy and matplotlib from sources, making sure 'python setup.py install' was invoking the self-installed python

- Installed ipython and whatnot using easy_install

I haven't tested this extensively, but seems to work fine for terminal work at least. Can't see why this would upset the system python in any way, and also root privileges are not needed for this method.

Ben (Tue, November 3rd, 2009, 1:16pm UTC)

Thanks for the great writeup, I was having all sorts of issues after I upgraded to SL.

In case anyone else had the same problem: python was giving me a segfault whenever I tried to import a scipy subpackage. It turns out I had forgotten to fix my PYTHONPATH since I upgraded. Added that to .profile and everything is good!

Martin (Wed, November 4th, 2009, 7:15am UTC)

Hi! I spent many dreamless nights trying to revive numpy, scipy, mpl and ipython after the upgrade to Snow Leo. Now, following the howto above it more-or-less works. I just used native MacOSX option for graphics windows in matplotlib setup.cfg. But, I'd like to ask, do you also experience weird behavior in ipython (the lines are messed up when line editing, or when browsing the command history)? I suspect readline library, that it might have been corrupted by former installation. Am I right? Where and how can I recompile to make it woring, please?

rui (Fri, November 6th, 2009, 3:40pm UTC)

Thanks for building and for posting such an extensive and comprehensive list of instructions!

As a python 'newbie' & after many hours…I suceeded to follow untill 'numpy' installatiion. I did not complete the installation of 'scipy' nor 'mpl'. No apparent problems with 'ipython' installation.

Any further suggestions ? Perhaps another relevant question is what is the most effective way of verifying & cleaning previously installed python/numpy/mlp/ipython installations ?

The error in the scipy instalation seems to be related with the architecture type:
1 …..
2 lipo: can't figure out the architecture type of: /var/tmp//cchBKN4l.out
3 error: Command "c++ -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing
4 -fno-common -dynamic -DNDEBUG -g -O3 -Iscipy/interpolate/src
5 -I/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/core/include
6 -I/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c scipy/interpolate/src/interpolate.cpp
7 -o build/temp.macosx-10.3-fat-2.6/scipy/interpolate/src/interpolate.o" failed with exit status 1

…Similar issues seem to occur in mpl installation process:
1 ….
2 ld: warning: in /sw/lib/libfreetype.dylib, file is not of required architecture
3 ld: in /sw/lib/libxml2.2.dylib, file is not of required architecture for architecture ppc
4 collect2: ld returned 1 exit status
5 lipo: can't open input file: /var/tmp//ccyJmjBJ.out (No such file or directory)
6 error: command 'c++' failed with exit status 1

colourful.jp (Fri, November 6th, 2009, 10:58pm UTC)

Thank you for your article.
This article is helpful to me.

Jeff (Sat, November 7th, 2009, 9:15pm UTC)

I just did another fresh install of Snow Leopard on my test drive and going to try to address a number of issues brought up in the discussion forum, and to try to resolve some outstanding issues. I created a big OmnOutliner document of issues and forum comments and am trying to see if I can't learn something and solve an item or two.

You guys* are also putting my little blog system to a good test, so let me know if you think there is some particularly useful feature that it could use to make discussions such as this be smoother. For instance, I'll add email subscriptions to the forum discussions, but if you have a good idea, email me using the link at the very top of the page.

Jeff (Tue, November 10th, 2009, 3:41am UTC)

Ok, I have once again tested on a pristine copy of Snow Leopard (10.6.2) and built everything up from scratch (from latest stable sources) to verify that everything is working as advertised, touching up and slightly improving the main article in places.

As with Johnny, I have been unable to compile SciPy from any source while the /System NumPy is in place. Changes to PYTHONPATH, which do help python to use the right NumPy when I was testing things, are insufficient for me to compile SciPy. The only solution, which is surely wrong, has been to move the /System NumPy out of the way temporarily. I run into exactly the same show-stopping error mentioned by rui otherwise.

I have tried the method mentioned of compiling matplotlib by updating setupext.py, but then found that there was no libfreetype to link against, leading to errors like those found by Niall, so I stuck with my method of editing the make.osx file and things like import matplotlib.pyplot then work fine. (This should also fix rui's libfreetype error.)

I have also noted and used syncolo's edits to make sure that gfortran creates 32/64-bit binaries and have updated the article accordingly. Not sure if this ends up making a difference here, but it's good to get things correct.

That said, as Richard brought up way up there, one still cannot get this stack to run with python in 32-bit mode. Drivin' me crazy. Anyone able to figure this out?

Xavier, sorry about losing some of your comments to the spam filter, but happy that things are working. Let me know (anyone) if comments get lost and I can dig them out if desired.

I should mention, for those following the RSS feed for this discussion forum, that the SciPy SuperPack is now available for 64-bit Snow Leopard builds, and is really fantastically simple to install. Had it been available for me, I'd have never ended up writing this entry, but at least I learned a lot and can now boldly build other things in this area, and of course be of help to others.

Stefan (Mon, November 16th, 2009, 3:58pm UTC)

Thanks for this post. It was very helpful to me when I was trying to get these packages to work on a ppc leopard 10.5 machine (for which epd is not available). Everything seems to be working.

I wanted to report that I had success with the idea to put

'darwin' : ['/Developer/SDKs/MacOSX10.5.sdk/usr/X11/'],

to get the freetype headers in the compliation of matplotlib.
Niall's command did not cause a crash and the commands from the frontpage of the matplotlib homepage produce a histogram as they should.

gfortran chocked on "-arch ppc" but applying the patch from http://projects.scipy.org/numpy/ticket/1087 or upgrading to latest version of gfortran fixed that.

Running np.test() produced no errors but scipy.test() produced 8 but I got rid of seven of them by applying the changes suggested here http://mail.scipy.org/pipermail/scipy-dev/2009-March/011599.html (with np instead of nm). I didn't investigate the remaining error.

Finally, it is possible that the problems you had with the quad tutorial examples simply stem from the line

from math import exp

which would more robustly be

from numpy import exp

Darren (Thu, November 19th, 2009, 10:52am UTC)

I got vtk/mayavi working on snow leopard. I downloaded vtk-5.4.2, unzipped it, and made a build directory (vtkbuild) next to the resulting VTK directory. Then I cd into vtkbuild and run "cmake ../VTK". Next, edit vtkbuild/CMakeCache.txt to set:
//Build Verdict with shared libraries.
BUILDSHAREDLIBS:BOOL=ON

//Build architectures for OSX
CMAKEOSXARCHITECTURES:STRING=x8664

//Minimum OS X version to target for deployment (at runtime); newer
// APIs weak linked. Set to empty string for default value.
CMAKEOSXDEPLOYMENTTARGET:STRING=10.6

//Build shared libraries with rpath. This makes it easy to run
// executables from the build tree when using shared libraries,
// but removes install support.
VTKUSERPATH:BOOL=ON

//Wrap VTK classes into the Python language.
VTKWRAPPYTHON:BOOL=ON

//Arguments passed to "python setup.py install …" during installation.
VTKPYTHONSETUPARGS:STRING=

Next, I ran "export MACOSXDEPLOYMENT_TARGET=10.6", but this may not have been necessary.
Run "make -j 2"
Run "sudo make install"

After that I was able to install Mayavi in the usual way.

Darren (Thu, November 19th, 2009, 11:07am UTC)

I forgot a step. After editing CMakeCache.txt, it is necessary to run "cmake ../VTK" again before running "make -j 2". Sorry about that.

Christian (Fri, November 20th, 2009, 6:44am UTC)

Thank you first of all that my beloved scipy/numpy/matplotlib works again after installing SL!

Regarding the comment from Sergei, I had the same problem that the matplotlib library was not found. I saw that it was placed in the folder /usr/local/lib/python2.6/site-packages instead of the PYTHONPATH at /Library/Python/2.6/site-packages.

I made the quick and dirty fix by copying the files into this folder as well, and now everything works like a charm. Thanks very much. I can be productive again!

Darren (Fri, November 20th, 2009, 1:47pm UTC)

Concerning building vtk, it turns out that setting VTKUSERPATH:BOOL=ON is a bad idea. Instead, add /usr/local/lib/vtk-5.4 to DYLDLIBRARYPATH (I did so in ~/.profile).

Michael (Tue, November 24th, 2009, 2:16am UTC)

Thanks for putting these instructions together. For some reason the superpack fails for me, so I am trying to build from source. I have a problem that sounds similar to what Rui is seeing. The numpy build/install works fine, but "setup.py install" fails for scipy. After a bunch of errors, I get this:

lipo: can't figure out the architecture type of: /var/tmp//ccmaLUEy.out
error: Command "c++ -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 -Iscipy/interpolate/src -I/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/core/include -I/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c scipy/interpolate/src/interpolate.cpp -o build/temp.macosx-10.3-fat-2.6/scipy/interpolate/src/interpolate.o" failed with exit status 1

It appears that for some reason the scipy install is not looking for the right version of one of the compilers (or something along those lines).

Does anyone have any ideas?

thanks.

Jeff (Tue, November 24th, 2009, 2:44am UTC)

Michael, make sure you set your environment variables, as with step 4. It looks like you're build a PPC/i386 version, so the architectures won't line up.

Michael (Tue, November 24th, 2009, 3:09am UTC)

Thanks for the quick response. I have all my environment variables set. I agree it looks like the environment is wrong, but I can't figure out where the environment is getting reset. I'll play around with it some more, but any other suggestions would be greatly appreciated.

Jeff (Tue, November 24th, 2009, 10:17pm UTC)

Appologies to Niall, Xavier, Martin and Michael. I've realized my spam filter has caught several extra fish in its net, but I'll try to see what tripped it up.

Michael (Tue, November 24th, 2009, 10:31pm UTC)

I figured out the above issue. You were right- the environment was getting un-set when I ran sudo. I needed to use sudo -E to make sure the environment carried over. This might help Rui as well.

Now, unfortunately I am having another problem. Everything built properly, but I can't seem to import what I need from actual python code. I get the following error:

1 from scipy.linalg import norm, inv
2 File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/linalg/init.py", line 8, in <module>
3 from basic import *
4 File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/linalg/basic.py", line 17, in <module>
5 from lapack import getlapackfuncs
6 File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/linalg/lapack.py", line 17, in <module>
7 from scipy.linalg import flapack
8 ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/linalg/flapack.so, \
9 2): Symbol not found: f2pywrapdlamch
10 Referenced from: /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/scipy/linalg/flapack.so
11 Expected in: dynamic lookup

Does this look familiar?

Thanks for all of your help.

Martin (Tue, November 24th, 2009, 10:37pm UTC)

Well, I realized that ipython uses an incomplete readline library which ipython calls libedit. To make it working I downloaded the original gnu readline library (written in C), compiled it with -arch x86_64 flag, than reinstall python libraries readline and ipython and it works! Also there exist a egg compiled with on Snow Leopard (64bit) python 2.6.1 mentioned in Zachary Voase's blog.

Mark (Wed, November 25th, 2009, 12:23am UTC)

Thank you so much for this tutorial! I am using a version of Snow Leopard that wasn't a clean install but an upgrade from Leopard and almost everything worked. The only problem I had was with the MatPlotLib part. I used Jean-Louis' advice and everything then went smoothly! I had a terrible time figuring this out myself since the scipy superpackage wasn't working for me and individual installs gave me all sorts of problems without having a clean python install. Thanks for making my day!!!

Lisa (Fri, December 4th, 2009, 11:23am UTC)

Thanks for the tips!

I've been able to install matplotlib following these steps. However, I am having a problem plotting. I get the following error when I try to do a simple plot (i.e. plot([1,2,3])):

File "/Users/lisa/.local/lib/python2.6/site-packages/matplotlib/backends/backendtkagg.py", line 158, in init
master=self.tkcanvas, width=w, height=h)
File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-tk/Tkinter.py", line 3284, in init
Image.init(self, 'photo', name, cnf, master, **kw)
File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-tk/Tkinter.py", line 3240, in init
self.tk.call(('image', 'create', imgtype, name,) + options)
TclError: integer value too large to represent

Does anyone know what is causing my problem?

Thanks.

Jun T. (Wed, December 16th, 2009, 3:41am UTC)

Hi All,

As pointed out by may people here, sudo resets PYTHONPATH and causes some problems, unless you modify sudoers as suggested by Darren.

I just want to point out that, if you are using Apple's python, and if you have an admin privilege then you need not sudo when you do 'setup.py install'; admin group has write permission of /Library/Python/ (and its sub directories).

Forgive me if this is well known.

Jun T. (Wed, December 16th, 2009, 3:44am UTC)

Oops! Sorry for the boldfaces. (I need 'preview' …)

Jun T. (Wed, December 16th, 2009, 3:47am UTC)

Sorry again. I hope this stops the boldface…

Jeff (Wed, December 16th, 2009, 3:49am UTC)

Thanks for making the point about sudo, Jun. I'll update the article to mention that above if I get a few minutes (feeling too lazy just now).

(I quickly edited your 1^st comment to fix the bold tag issue. I do need to add a preview to comments. Perhaps even a nice "live" preview. Again, when I get some free time.)

Chris (Sun, December 27th, 2009, 7:01pm UTC)

Unfortunately the builds on macinscience.org have ground to a halt, due to an unresolved (and perhaps unresolvable) bug in more recent revisions of the numpy code base that prevents me from making usable builds in 64-bit Python:

http://projects.scipy.org/numpy/ticket/1343

Until this is fixed, and I have little reason to be optimistic that it will, there will be no new builds of the Scipy Superpack.

Jeff (Sun, December 27th, 2009, 7:28pm UTC)

Thanks for the information, Chris. Here's hoping things get better on that front.

Domingo (Fri, January 29th, 2010, 10:34am UTC)

Thanks everybody for the comments. One important advice (already said) is to uninstall whatever other Python distribution in the machine and leave just the Apple (64 bits) distribution.

I had the MacPython distribution installed and it made impossible to compile PyQt4. After uninstalling MacPython everything went fine.

To uninstall MacPython: Remove /Library/Frameworks/Python.framework and everything in it; remove /Applications/MacPython-2.3 and everything in it; in /usr/local/bin, remove idle, idle2.5, pydoc, pydoc2.5, python, python-config, python2.5, python2.5-config, pythonw, pythonw2.5, smtpd.py, smtpd2.5.py.

(Taken from http://homepages.cwi.nl/~jack/macpython/uninstall.html and http://phd.kt.pri.ee/2008/11/27/how-to-tame-python-and-uninstall-packages-in-mac-os-x/ )

Franck (Thu, February 11th, 2010, 9:46am UTC)

Will you marry me ?

Seriously, I'm completely new to mac (with a fair experience with Linux), and have been pulling my hair to get all that to work. Followed your post step by step and it worked perfectly. You just saved my sanity, thanks !!

Jeff (Thu, February 11th, 2010, 12:22pm UTC)

Ha! That's awesome, Franck. Happy it helped.

Tomek (Mon, February 22nd, 2010, 4:02pm UTC)

Fantastic! :D

Adam (Thu, March 4th, 2010, 10:55pm UTC)

I've been running into trouble recently. Everything except scipy worked fine for a while, then scipy worked fine and matplotlib's TclTk broke when I re-installed.

I get the following error:
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/matplotlib/path.so, 2): Symbol not found: emutlsgetaddress

Any tips? I've been trying to hunt this down for hours and am now just frustrated.

Thanks.

ChrisC (Sun, March 7th, 2010, 6:40am UTC)

Hi Jeff,

Thanks so much for this. After a bit of messing around, and largely thanks to this excellent tutorial, I've got things working well.

Quick question. I'm currently running python 2.6.1. Being a python newbie, I'm not sure if upgrading python to 2.6.4 (or 3) will break everything so far. Is it possible to upgrade and still use numpy and scipy? Or will upgrading require a complete rebuild?

Tsuname (Thu, March 11th, 2010, 3:09am UTC)

Nicely done! I was banging myself in the head trying to fix the setup.cfg. Thanks

Marcelo (Mon, March 15th, 2010, 12:41am UTC)

Hi Jeff, nice article, but got a problem at the time installing numpy:

python setup.py build --fcompiler=gnu95

The message was:

"Cannot compiler 'Python.h'. Perhaps you need to "\
SystemError: Cannot compiler 'Python.h'. Perhaps you need to install python-dev|python-devel.

Thanks a lot !
Marcelo

Renaud (Mon, March 15th, 2010, 9:49pm UTC)

Thanks a lot Jeff!

Prasanna Kumar Thiagarajan (Tue, March 30th, 2010, 5:35pm UTC)

Hi,
The prob that I get while installing the matplot is :

REQUIRED DEPENDENCIES
numpy: 2.0.0.dev8307
freetype2: found, but unknown version (no pkg-config)
* WARNING: Could not find 'freetype2' headers in any
* of '.', './freetype2'.
and after this I get a list of errors while trying to build all the '.h' and '.cpp' files resulting in spitting out
" make: *** [mpl_build] Error 1" finally.

I tried all that was posted about regarding freetype2 , but the prob still exists.. Kindly help me out here.

Many thanks.
Prasanna

Ben (Sat, April 3rd, 2010, 8:33pm UTC)

Thank you! Very helpful.

fyi, for matplotlib, i just did sudo make -f make.osx mplbuild mplinstall. I had all the dependencies installed and it gave me problems when i tried fetch and deps

Also, for 64-bit python, I had to compile (2.6.5) from source with
./configure --enable-framework --enable-universalsdk=/ --with-universal-archs=intel
make
sudo make install

Ben (Sun, April 4th, 2010, 12:52am UTC)

Actually, matplotlib was a bit of a headache. I have a binary GUI installer that i can post (5.6 M). I believe the required build settings are

CFLAGS=-isysroot /Developer/SDKs/MacOSX10.6u.sdk -arch i386 -arch x8664 -I/usr/local/include -I/usr/local/include/freetype2
LDFLAGS=-arch i386 -arch x8664 -L/usr/local/lib

edit makefile, remove zlib from freetype and png
edit setupext.py, change darwin path to '/usr/local',/usr/local/lib'
edit setupext.py to include this change

def addft2fontflags(module):
'Add the module flags to ft2font extension'
addnumpyflags(module)
if not getpkgconfig(module, 'freetype2'):
module.libraries.extend(['freetype', 'z'])
addbaseflags(module)

basedirs = module.includedirs[:] # copy the list to avoid inf loop!
# include dir is wrong, set manually
#for d in basedirs:
# module.includedirs.append(os.path.join(d, 'freetype2'))
# p = os.path.join(d, 'lib/freetype2/include')
# if os.path.exists(p): module.includedirs.append(p)
# p = os.path.join(d, 'lib/freetype2/include/freetype2')
# if os.path.exists(p): module.includedirs.append(p)
p = '/usr/local/include/freetype2'

then build everything

sudo make -f make.osx fetch freetype png mplbuild mpl_install
sudo python setup.py install

Megan (Mon, April 5th, 2010, 2:48pm UTC)

Just wanted to confirm that switching from gfortran 4.5 to gfortran 4.2.3 fixes the 'wrong architecture' error when importing scipy sub-modules in ipython.

Using gfortran 4.5 I was receiving the following error when I tried to import any of the scipy sub-packages:

dlopen(/Users/mkaralus/lib/python/scipy/odr/odrpack.so, 2): no suitable image found. Did find:
/Users/mkaralus/lib/python/scipy/odr/odrpack.so: mach-o, but wrong architecture

After I reverted the gfortran compiler, deleted all previous installs and source directories, re-downloaded, re-built and re-installed numpy and scipy (after re-making UMFPACK) I successfully ridded myself of the error. It's too bad gfortran is buggy like that.

Faye (Thu, April 15th, 2010, 12:22am UTC)

Hello Jeff,

Thank you for the helpful tips. Everything is fine until make matplotlib. I got the following errors:

python2.6 -c 'import urllib; urllib.urlretrieve("http://www.zlib.net/zlib-1.2.3.tar.gz", "zlib-1.2.3.tar.gz")' &&\
python2.6 -c 'import urllib; urllib.urlretrieve("http://downloads.sourceforge.net/project/libpng/libpng-stable/1.2.39/libpng-1.2.39.tar.gz", "libpng-1.2.39.tar.gz")' &&\
python2.6 -c 'import urllib; urllib.urlretrieve("http://download.savannah.gnu.org/releases/freetype/freetype-2.3.11.tar.bz2", "freetype-2.3.11.tar.bz2")'
export PKGCONFIGPATH="/usr/local/lib/pkgconfig" &&\
rm -rf zlib-1.2.3 &&\
tar xvfj zlib-1.2.3.tar.gz &&\
cd zlib-1.2.3 &&\
export MACOSXDEPLOYMENTTARGET=10.6 &&\
export CFLAGS="-arch i386 -arch x8664 -I/usr/local/include -I/usr/local/include/freetype2 -isysroot /Developer/SDKs/MacOSX10.6.sdk" &&\
export LDFLAGS="-arch i386 -arch x8664 -L/usr/local/lib -syslibroot,/Developer/SDKs/MacOSX10.6.sdk" &&\
./configure --prefix=/usr/local&&\
MACOSXDEPLOYMENTTARGET=10.6 CFLAGS="-arch i386 -arch x8664 -I/usr/local/include -I/usr/local/include/freetype2 -isysroot /Developer/SDKs/MacOSX10.6.sdk" LDFLAGS="-arch i386 -arch x8664 -L/usr/local/lib -syslibroot,/Developer/SDKs/MacOSX10.6.sdk" make -j3 install&& \
unset MACOSXDEPLOYMENTTARGET
tar: Unrecognized archive format: Inappropriate file type or format
tar: Error exit delayed from previous errors.
make: *** [zlib] Error 1

And I use OS X 10.6.2, matplotlib 0.99.1.1. Please help me. Many thanks.

Faye

Souheil Inati (Wed, April 21st, 2010, 12:28pm UTC)

I ran into some trouble compiling UMFPACK. The Nov 30, 2009, version 5.5.0 version of UMFPACK, seems to require the Cholesky stuff. I ended up setting
UMFPACK_CONFIG = -DNCHOLMOD
at line 154 of UFconfig/UFconfig.mk

Has anyone else seen this behavior?

-Souheil

Megan (Wed, April 21st, 2010, 8:02pm UTC)

I had some trouble installing matplotlib on MAC 10.6.3 from source but finally succeeded. Thought I would share my insights. Follow the instructions above except for the following……

(1) Use the stable distribution from sourceforge, not what's pulled from the subversion repository.

(2) Change ZLIBVERSION=1.2.5 (The 1.2.3 version pulled from the zlib website won't uncompress properly)

(3) If you have installed numpy 2.0 you must change setupext.py. The way the code checks for the proper numpy verison (greater than 1.1) is buggy for version 2.0. i.e. For 2.0, 2>=1 but 0 isn't yet 2.0 is definitely greater than 1.1. Change Line 495 from

if not (int(nn[0]) >= 1 and int(nn[1]) >= 1):

to

if not (int(nn[0]) >= 1):

Make the same change on line 149 in lib/matplotlib/init.py

Now run the make command listed above.

Good luck!

S.V. (Sun, May 23rd, 2010, 5:03pm UTC)

This worked for 10.6.3 (I didnt install neither FFTW nor UMFPACK)

1) Update the Python to the version 2.6.5 in your machine.

Python 2.6.5 Mac OS X Installer Disk Image (for Mac OS X 10.3 through 10.6) http://www.python.org/ftp/python/2.6.5/python-2.6.5-macosx10.3-2010-03-24.dmg

2) Modify the environment variable $PATH in order that the first entry be:
/Library/Frameworks/Python.framework/Versions/2.6/bin

3)In the terminal, type: which python
This is a check to see if step 2 was done correctly.

4)Download the package setuptools-0.6c11-py2.6.egg
http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c11-py2.6.egg#md5=bfa92100bd772d5a213eedd356d64086

5)In the terminal, type: sh setuptools-0.6c11-py2.6.egg

6)In the terminal, type: which easyinstall-2.6

7)Download the package ipython-0.10-py2.6.egg
http://ipython.scipy.org/dist/0.10/ipython-0.10-py2.6.egg

8)In the terminal, type: easyinstall-2.6 ipython-0.10-py2.6.egg

9)Download and install the package numpy
http://sourceforge.net/projects/numpy/files/NumPy/1.4.1/numpy-1.4.1-py2.6-python.org.dmg/download

10)Download and install the package scipy
http://sourceforge.net/projects/scipy/files/scipy/0.7.2/scipy-0.7.2-py2.6-python.org.dmg/download

11)Install the package matplotlib
http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.1/matplotlib-0.99.1.1-py2.6-macosx10.5.dmg/download

PV (Fri, June 4th, 2010, 8:36pm UTC)

Great instructions S.V. — worked a charm.
Thanks

Marco (Sat, June 5th, 2010, 12:31am UTC)

I successfully installed ipython 32bit and it is running smoothly.
The trick was to build matplotlib using universal (32b & 64b) versions of libpng,zlib, and freetype.
I obtained this packages using macports. For instance to install freetype I use
sudo port install freetype +universal
Try it and have fun!
Marco

Ranjit (Fri, June 25th, 2010, 1:43pm UTC)

Compiling UMFPACK fails for me. Any help in figuring this out would be appreciated. Here's the error message:

../Source/umfcholmod.c:18:21: error: cholmod.h: No such file or directory
../Source/umfcholmod.c: In function ‘umficholmod’:
../Source/umfcholmod.c:58: error: ‘cholmodsparse’ undeclared (first use in this function)
../Source/umfcholmod.c:58: error: (Each undeclared identifier is reported only once
../Source/umfcholmod.c:58: error: for each function it appears in.)
../Source/umfcholmod.c:58: error: expected ‘;’ before ‘Amatrix’
../Source/umfcholmod.c:59: error: ‘cholmodfactor’ undeclared (first use in this function)
../Source/umfcholmod.c:59: error: ‘L’ undeclared (first use in this function)
../Source/umfcholmod.c:60: error: ‘cholmodcommon’ undeclared (first use in this function)
../Source/umfcholmod.c:60: error: expected ‘;’ before ‘cm’
../Source/umfcholmod.c:81: error: ‘cm’ undeclared (first use in this function)
../Source/umfcholmod.c:82: error: ‘CHOLMODSIMPLICIAL’ undeclared (first use in this function)
../Source/umfcholmod.c:93: error: ‘CHOLMODAMD’ undeclared (first use in this function)
../Source/umfcholmod.c:93: error: ‘CHOLMODCOLAMD’ undeclared (first use in this function)
../Source/umfcholmod.c:100: error: ‘CHOLMODMETIS’ undeclared (first use in this function)
../Source/umfcholmod.c:110: error: ‘CHOLMODNATURAL’ undeclared (first use in this function)
../Source/umfcholmod.c:120: error: ‘CHOLMODNESDIS’ undeclared (first use in this function)
../Source/umfcholmod.c:144: error: ‘A’ undeclared (first use in this function)
../Source/umfcholmod.c:144: error: ‘Amatrix’ undeclared (first use in this function)
../Source/umfcholmod.c:157: error: ‘CHOLMODINT’ undeclared (first use in this function)
../Source/umfcholmod.c:158: error: ‘CHOLMODPATTERN’ undeclared (first use in this function)
../Source/umfcholmod.c:159: error: ‘CHOLMODDOUBLE’ undeclared (first use in this function)
../Source/umfcholmod.c:170: error: ‘AT’ undeclared (first use in this function)
../Source/umfcholmod.c:171: error: ‘S’ undeclared (first use in this function)
../Source/umfcholmod.c:202: error: ‘CHOLMODGIVEN’ undeclared (first use in this function)
../Source/umfcholmod.c:18:21: error: cholmod.h: No such file or directory
../Source/umfcholmod.c: In function ‘umficholmod’:
../Source/umfcholmod.c:58: error: ‘cholmodsparse’ undeclared (first use in this function)
../Source/umfcholmod.c:58: error: (Each undeclared identifier is reported only once
../Source/umfcholmod.c:58: error: for each function it appears in.)
../Source/umfcholmod.c:58: error: expected ‘;’ before ‘Amatrix’
../Source/umfcholmod.c:59: error: ‘cholmodfactor’ undeclared (first use in this function)
../Source/umfcholmod.c:59: error: ‘L’ undeclared (first use in this function)
../Source/umfcholmod.c:60: error: ‘cholmodcommon’ undeclared (first use in this function)
../Source/umfcholmod.c:60: error: expected ‘;’ before ‘cm’
../Source/umfcholmod.c:81: error: ‘cm’ undeclared (first use in this function)
../Source/umfcholmod.c:82: error: ‘CHOLMODSIMPLICIAL’ undeclared (first use in this function)
../Source/umfcholmod.c:93: error: ‘CHOLMODAMD’ undeclared (first use in this function)
../Source/umfcholmod.c:93: error: ‘CHOLMODCOLAMD’ undeclared (first use in this function)
../Source/umfcholmod.c:100: error: ‘CHOLMODMETIS’ undeclared (first use in this function)
../Source/umfcholmod.c:110: error: ‘CHOLMODNATURAL’ undeclared (first use in this function)
../Source/umfcholmod.c:120: error: ‘CHOLMODNESDIS’ undeclared (first use in this function)
../Source/umfcholmod.c:144: error: ‘A’ undeclared (first use in this function)
../Source/umfcholmod.c:144: error: ‘Amatrix’ undeclared (first use in this function)
../Source/umfcholmod.c:157: error: ‘CHOLMODINT’ undeclared (first use in this function)
../Source/umfcholmod.c:158: error: ‘CHOLMODPATTERN’ undeclared (first use in this function)
../Source/umfcholmod.c:159: error: ‘CHOLMODDOUBLE’ undeclared (first use in this function)
../Source/umfcholmod.c:170: error: ‘AT’ undeclared (first use in this function)
../Source/umfcholmod.c:171: error: ‘S’ undeclared (first use in this function)
../Source/umfcholmod.c:202: error: ‘CHOLMODGIVEN’ undeclared (first use in this function)
lipo: can't figure out the architecture type of: /var/folders/70/70pV-+FxFmyoJ7Qp1QdRcE+++TM/-Tmp-//ccrxhS1q.out
make[1]: *** [umficholmod.o] Error 1
make: *** [all] Error 2

Theo (Sat, June 26th, 2010, 8:34pm UTC)

Exact same error as Ranjit. Frustrating!

Jeff (Sat, June 26th, 2010, 8:47pm UTC)

Very interesting and annoying I agree, Ranjit and Theo. I wonder what has changed to have excluded the umf_cholmod.c file. I'll try to track this down. This must be something that has happened recently.

Theo (Sat, June 26th, 2010, 9:41pm UTC)

Just found out the issue — like Souheil suggested, the newer version of UMFPACK requires CHOLMOD.
I didn't try installing CHOLMOD yet, but setting
UMFPACK_CONFIG = -DNCHOLMOD
does fix my problem.

Grace (Wed, July 28th, 2010, 10:23am UTC)

Hey Jeff and other users,

I've been trying to setup numpy and scipy to use pytables.
I tried a dozen methods, including the ones that are list in Jeff's blog.
SV's method is the only current working method. I would not suggest trying to compile numpy on snow leopard from source. See below for details.

I am running Snow Leopard 10.6.4
Running python 2.6.1

First, just to confirm some of the other posters from around May-June 2010, yes I also could not compile UMFPACK because of the missing
../Source/umfcholmod.c:18:21: error: cholmod.h
It used to work once upon a time, but then I guess stuff happened. Someone needs to submit a patch for it :)

Second, I"ve tried installing numpy-1.4.1 using easyinstall on top of python v2.6.1. This fails miserably when compiling, even after I installed gfortran successfully and setting the architecture to x8664 etc. Although easyinstall seems to indicate that it 'installed' (if you ignore the billions of warnings), only numpy version 1.2.1 can be imported.

Then I tried install numpy-1.4.1 dmg ontop of python 2.6.1, but I get the 'need System python at version 2.6' error from the installer.

Furthermore, I've also installed python 2.7 from python.org for mac os x. Note: numpy dmg works ONLY at 2.6 not 2.6 or greater. Trying to compile numpy from source or using easy_install-2.7 etc still fails probably because of UMFPACK not being able to compile properly.

FINALLY, the solution that worked was SV's solution (Date (Sun, May 23^rd, 2010, 5:03pm CDT))
The key was upgrading to python 2.6.5. That seemed to have worked.

Rahul (Thu, July 29th, 2010, 2:13pm UTC)

Thank you so much S.V. for your instructions.
Was trying for oh so long to get scipy to work on Snow Leopard.

Matthew (Thu, August 26th, 2010, 5:41am UTC)

In order to download ipython, I had to use:

curl -O http://ipython.scipy.org/dist/0.10/ipython-0.10.tar.gz

instead of:

curl -O http://ipython.scipy.org/dist/ipython-0.10.tar.gz

Google Reklamları (Sun, September 5th, 2010, 6:26pm UTC)

Thank you so much S.V. for your instructions.
Was trying for oh so long to get scipy to work on Snow Leopard.

web tasarım ankara (Thu, September 9th, 2010, 6:02am UTC)

*
Thank you so much S.V. for your instructions.
Was trying for oh so long to get scipy to work on Snow Leopard.

Yi (Tue, October 5th, 2010, 11:53am UTC)

Jeff,

Excellent instructions!

It helps me to build my fftw-3.2.2, numpy1.4.1 and scipy0.8.0 package from source in Opensue 11.1. My system has python2.4.4, numpy1.4.1 and scipy0.8.0 now.

I have gfortran4.3 installed in my system.
Only set environment variables using
export CFLAG='-m64'
epxort FFLAG='-m64'
when build scipy.

Yi

Gilles (Thu, October 28th, 2010, 3:56am UTC)

Hi all,

First, thank you S.V. for the description!

Second, I was wondering if any of you experienced a modification of Snow Leopard after having installed all these packages. My computer is now taking ages to start ! The first part of the boot (the one until the login menu) seems to take the same time, but after having login, Snow Leopard is freezing.

Note that when using the safe mode, the boot time after login comes back to normal.

Does anybody know the reason for that, and a possible solution ?!

Thanks in advance for your answer,
Gilles

Joe (Sun, November 28th, 2010, 11:45am UTC)

For those of you who are using fink, matplotlib is available through fink. It takes care of installing all required packages and save you a lot of headaches :)

John Harrison (Wed, April 27th, 2011, 2:48pm UTC)

This has been very helpful. I was finally able to get matplotlib and pylab to work as 64 bit binaries under python2.7 in snow leopard. What's more, I got it to work in a virtual environment. In order to do so I had to edit the matplotlib make.osx file to point to the python in my virtual environment.

All of this has taken me about a day and a half. The state of these tools on snow leopard is really unfortunate.

ankara web tasarım (Tue, May 17th, 2011, 7:20am UTC)

thank you S.V. for the description

ankara düğün salonu (Sat, June 4th, 2011, 2:58am UTC)

Thank you so much S.V. for your instructions.
Was trying for oh so long to get scipy to work on Snow Leopard.

ankara dalgıç pompa (Sat, June 4th, 2011, 2:59am UTC)

Very interesting and annoying I agree, Ranjit and Theo. I wonder what has changed to have excluded the umf_cholmod.c file. I'll try to track this down. This must be something that has happened recently.

google reklam ankara (Sun, June 19th, 2011, 7:42pm UTC)

thank you S.V. for the description

Marcel (Thu, June 30th, 2011, 1:11am UTC)

Hi all,

When I try to install on my Mac OS 10.6.7 and Python 2.6.5 , it gives an error in the compilation of UMFPACK:

After the command make, it gives this output:

( cd ../AMD ; make library )
( cd Lib ; make )
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -c ../Source/amdglobal.c -o amdglobal.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDINT -c ../Source/amdaat.c -o amdiaat.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDINT -c ../Source/amd1.c -o amdi1.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDINT -c ../Source/amd2.c -o amdi2.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDINT -c ../Source/amddump.c -o amdidump.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDINT -c ../Source/amdpostorder.c -o amdipostorder.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDINT -c ../Source/amdposttree.c -o amdiposttree.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDINT -c ../Source/amddefaults.c -o amdidefaults.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDINT -c ../Source/amdorder.c -o amdiorder.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDINT -c ../Source/amdcontrol.c -o amdicontrol.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDINT -c ../Source/amdinfo.c -o amdiinfo.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDINT -c ../Source/amdvalid.c -o amdivalid.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDINT -c ../Source/amdpreprocess.c -o amdipreprocess.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDLONG -c ../Source/amdaat.c -o amdlaat.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDLONG -c ../Source/amd1.c -o amdl1.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDLONG -c ../Source/amd2.c -o amdl2.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDLONG -c ../Source/amddump.c -o amdldump.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDLONG -c ../Source/amdpostorder.c -o amdlpostorder.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDLONG -c ../Source/amdposttree.c -o amdlposttree.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDLONG -c ../Source/amddefaults.c -o amdldefaults.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDLONG -c ../Source/amdorder.c -o amdlorder.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDLONG -c ../Source/amdcontrol.c -o amdlcontrol.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDLONG -c ../Source/amdinfo.c -o amdlinfo.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDLONG -c ../Source/amdvalid.c -o amdlvalid.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDLONG -c ../Source/amdpreprocess.c -o amdlpreprocess.o
ar cr libamd.a amdglobal.o amdiaat.o amdi1.o amdi2.o amdidump.o amdipostorder.o amdiposttree.o amdidefaults.o amdiorder.o amdicontrol.o amdiinfo.o amdivalid.o amdipreprocess.o amdlaat.o amdl1.o amdl2.o amdldump.o amdlpostorder.o amdlposttree.o amdldefaults.o amdlorder.o amdlcontrol.o amdlinfo.o amdlvalid.o amdlpreprocess.o
ar: libamd.a is a fat file (use libtool(1) or lipo(1) and ar(1) on it)
ar: libamd.a: Inappropriate file type or format
make[2]: *** [libamd.a] Error 1
make[1]: *** [library] Error 2
make: *** [all] Error 2

Does anyone know how to fix it ?

google reklam vermek (Sun, July 17th, 2011, 9:37am UTC)

thank you S.V. for the description

web tasarım ankara (Sun, July 17th, 2011, 9:38am UTC)

Great instructions S.V. — worked a charm.
Thanks

davidl (Mon, October 3rd, 2011, 1:38pm UTC)

Can anyone recommend a solution for this problem on SnowLeopard 10.6.8?

make
( cd ../AMD ; make library )
( cd Lib ; make )
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -c ../Source/amdglobal.c -o amdglobal.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDINT -c ../Source/amdaat.c -o amdiaat.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDINT -c ../Source/amd1.c -o amdi1.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDINT -c ../Source/amd2.c -o amdi2.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDINT -c ../Source/amddump.c -o amdidump.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDINT -c ../Source/amdpostorder.c -o amdipostorder.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDINT -c ../Source/amdposttree.c -o amdiposttree.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDINT -c ../Source/amddefaults.c -o amdidefaults.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDINT -c ../Source/amdorder.c -o amdiorder.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDINT -c ../Source/amdcontrol.c -o amdicontrol.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDINT -c ../Source/amdinfo.c -o amdiinfo.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDINT -c ../Source/amdvalid.c -o amdivalid.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDINT -c ../Source/amdpreprocess.c -o amdipreprocess.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDLONG -c ../Source/amdaat.c -o amdlaat.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDLONG -c ../Source/amd1.c -o amdl1.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDLONG -c ../Source/amd2.c -o amdl2.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDLONG -c ../Source/amddump.c -o amdldump.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDLONG -c ../Source/amdpostorder.c -o amdlpostorder.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDLONG -c ../Source/amdposttree.c -o amdlposttree.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDLONG -c ../Source/amddefaults.c -o amdldefaults.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDLONG -c ../Source/amdorder.c -o amdlorder.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDLONG -c ../Source/amdcontrol.c -o amdlcontrol.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDLONG -c ../Source/amdinfo.c -o amdlinfo.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDLONG -c ../Source/amdvalid.c -o amdlvalid.o
gcc -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 -I../Include -I../../UFconfig -DDLONG -c ../Source/amdpreprocess.c -o amdlpreprocess.o
ar cr libamd.a amdglobal.o amdiaat.o amdi1.o amdi2.o amdidump.o amdipostorder.o amdiposttree.o amdidefaults.o amdiorder.o amdicontrol.o amdiinfo.o amdivalid.o amdipreprocess.o amdlaat.o amdl1.o amdl2.o amdldump.o amdlpostorder.o amdlposttree.o amdldefaults.o amdlorder.o amdlcontrol.o amdlinfo.o amdlvalid.o amdlpreprocess.o
ar: libamd.a is a fat file (use libtool(1) or lipo(1) and ar(1) on it)
ar: libamd.a: Inappropriate file type or format
make[2]: *** [libamd.a] Error 1
make[1]: *** [library] Error 2

anthony (Fri, November 18th, 2011, 4:47am UTC)

If anyone is still having trouble with UMFPACK and AMD, I am no expert, but have managed to get it to build. There are more dependencies within these libraries now, so the simplest option seemed to build the whole SuiteSparse, which meant making some changes to disable Metis.

A couple of the Makefiles are also missing ranlib commands so these need to be added.

(This was on Lion but should be the same on Snow Leopard.)

( bash ) ✂
# UMFPACK and dependencies # Current versions at 17/11/11 # As the interdepencies are now quite convoluted, it is easiest to build the whole SuiteSparse # Some of the Makefiles are missing ranlib so need to add cd ~/build curl -O http://www.cise.ufl.edu/research/sparse/SuiteSparse/SuiteSparse-3.6.1.tar.gz tar xf SuiteSparse-3.6.1.tar.gz cd SuiteSparse mate UFconfig/UFconfig.mk # Lines 135-141 # Disable Metis ## METISPATH = ../../metis-4.0 ## METIS = ../../metis-4.0/libmetis.a # ## If you use CHOLMODCONFIG = -DNPARTITION then you must use the following ## options: #METISPATH = #METIS = # (i.e. the last two lines are not commented out) # Line 197 #CHOLMODCONFIG = -DNPARTITION # Line 211 #SPQRCONFIG = -DNPARTITION # Lines 287-293 ## As recommended by macports, http://suitesparse.darwinports.com/ ## I've tested them myself on Mac OSX 10.6.1 (Snow Leopard), on my MacBook Air. #F77 = gfortran #CC = gcc ### shouldn't need this ??? #CFLAGS = -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664 #BLAS = -framework Accelerate #LAPACK = -framework Accelerate mate CCOLAMD/Lib/Makefile # Line 21 (insert after $(AR) libccolamd.a ccolamd.o ccolamdl.o ccolamdglobal.o) #$(RANLIB) libccolamd.a mate COLAMD/Lib/Makefile # Line 21 (insert after $(AR) libcolamd.a colamd.o colamdl.o colamdglobal.o) #$(RANLIB) libcolamd.a mate mate UFconfig/Makefile # Line 16 (insert after $(AR) libufconfig.a UFconfig.o) #$(RANLIB) libufconfig.a make
1 # UMFPACK and dependencies
2 # Current versions at 17/11/11
3 # As the interdepencies are now quite convoluted, it is easiest to build the whole SuiteSparse
4 # Some of the Makefiles are missing ranlib so need to add
5 cd ~/build
6 curl -O http://www.cise.ufl.edu/research/sparse/SuiteSparse/SuiteSparse-3.6.1.tar.gz
7 tar xf SuiteSparse-3.6.1.tar.gz
8 cd SuiteSparse
9 mate UFconfig/UFconfig.mk
10 # Lines 135-141
11 # Disable Metis
12 ## METISPATH = ../../metis-4.0
13 ## METIS = ../../metis-4.0/libmetis.a
14 #
15 ## If you use CHOLMODCONFIG = -DNPARTITION then you must use the following
16 ## options:
17 #METISPATH =
18 #METIS =
19 # (i.e. the last two lines are not commented out)
20 # Line 197
21 #CHOLMODCONFIG = -DNPARTITION
22 # Line 211
23 #SPQRCONFIG = -DNPARTITION
24 # Lines 287-293
25 ## As recommended by macports, http://suitesparse.darwinports.com/
26 ## I've tested them myself on Mac OSX 10.6.1 (Snow Leopard), on my MacBook Air.
27 #F77 [color= gfortran
28 #CC [color= gcc ### shouldn't need this ???
29 #CFLAGS = -O3 -fno-common -no-cpp-precomp -fexceptions -arch i386 -arch x8664
30 #BLAS = -framework Accelerate
31 #LAPACK = -framework Accelerate
32 mate CCOLAMD/Lib/Makefile
33 # Line 21 (insert after $(AR) libccolamd.a ccolamd.o ccolamdl.o ccolamdglobal.o)
34 #$(RANLIB) libccolamd.a
35 mate COLAMD/Lib/Makefile
36 # Line 21 (insert after $(AR) libcolamd.a colamd.o colamdl.o colamdglobal.o)
37 #$(RANLIB) libcolamd.a
38 mate mate UFconfig/Makefile
39 # Line 16 (insert after $(AR) libufconfig.a UFconfig.o)
40 #$(RANLIB) libufconfig.a
41 make

Marcelino Suzuki (Fri, September 21st, 2012, 6:53am UTC)

I just installed UMFPACK using partially Jeff's instructions. In fact since UMFPACK is now budled in the larger package SuiteSparse, the instructions are out of date, in particular
curl -O http://www.cise.ufl.edu/research/sparse/UFconfig/current/UFconfig.tar.gz
since this does not exists any longer

So I also tried instructions from http://stuffalsothings.blogspot.fr/2009/08/compiling-bleeding-edge-scipy-on-mac-os.html/MacOSX and kept getting the error:

ld: library not found for -lrt

basically I dowload the current version of Suitesparse at

http://www.cise.ufl.edu/research/sparse/SuiteSparse/current/

Unzip/Untar then went to
SuiteSparse/SuiteSparseconfig

and edited
SuiteSparseconfigMac.mk

I
commented the generic CF to keep the one with -DNTIMER

CF = $(CFLAGS) $(CPPFLAGS) $(TARGETARCH) -O3 -fexceptions -fPIC -DNTIMER
# CF = $(CFLAGS) $(CPPFLAGS) $(TARGETARCH) -O3 -fexceptions -fPIC

comment the generic LIB

# LIB = -lm

Under Mac options I had

F77 = gfortran
CF = $(CFLAGS) -O3 -fno-common -fexceptions -DNTIMER -no-cpp-precomp -arch x8664
BLAS = -framework Accelerate
LAPACK = -framework Accelerate
LIB = -lm
CC = gcc

Save the file and replace it as SuiteSparseconfig.mk

THIS LAST STEP IS QUITE IMPORTANT, since just changing the SuiteSparse to include the SuiteSparse/SuiteSparseconfigMac.mk will keep giving the annoying error:

ld: library not found for -lrt

I then edited the makefile to compile just
— ( cd SuiteSparseconfig/xerbla && $(MAKE) )
— ( cd SuiteSparse_config && $(MAKE) )
— ( cd UMFPACK && $(MAKE) )

then

make
make hb
make install

Subito (Mon, November 19th, 2012, 7:19pm UTC)

This has been very helpful. I was finally able to get matplotlib and pylab to work as 64 bit binaries under python2.7 in snow leopard. What's more, I got it to work in a virtual environment. In order to do so I had to edit the matplotlib make.osx file to point to the python in my virtual environment.

All of this has taken me about a day and a half. The state of these tools on snow leopard is really unfortunate.

seth williams (Thu, August 28th, 2014, 9:59am UTC)

Hey Jeff, these are some amazing codes on on installing a 64-bit stack of PyLab.

Leave a comment

Name:*

email: * = required

URL:

Comment:*
(allowed tags)