[SciPy-User] Problems building SciPy on OS X due to ppc64 issues

Karl-Dieter Crisman kcrisman at gmail.com
Wed Oct 13 11:16:04 EDT 2010


Hi, sorry for the delay.  This is on Intel OS X 10.6 (more than one
machine).  The previous poster knows a lot about build stuff, but
doesn't happen to have access to this type of system.

We have tried the latest fixes to Numpy which just remove ppc64 (or do
something smarter), and although that still might end up being an
issue, it isn't this problem.  I think that Robert's is the correct
analysis.  We are using gfortran-4.2 on Mac OS X 10.6 as an included
binary in Sage to do fortran compiling (which works fine for R and
Numpy, and until recently was fine for Scipy as well).  Also, I should
point out that g95 works great for Scipy 0.8 on our OS X 10.4 machines
(we are working on eventually migrating to gfortran, but unfortunately
this is difficult because of Sage's "batteries included" philosophy),
so different fortran compilers shouldn't be the issue per se, but the
extra option appears to be - compiling object code twice, is that
correct?

I know very little about how compiler options are set, so I don't know
where this would be coming from.  Where does this "compile options"
line usually come from in a typical Scipy build?  Is it somewhere in a
makefile or something (again, excuse my ignorance if this makes no
sense, I'm only guessing blindly).

Karl-Dieter Crisman

> -I/Applications/sage_builds/numpy/sage-4.6.alpha2/local/lib/python2.6/site-packages/numpy/core/include
> -c -c scipy/fftpack/src/dfftpack/dcosqb.f -o

Are the multiple "-c" options causing issues? From the build log, it
looks like "-c" is being added explicitly somewhere.

compile options:
'-I/Applications/sage_builds/numpy/sage-4.6.alpha2/local/lib/python2.6/site-packages/numpy/core/include
-c'

Exactly where did the gfortran compiler come from? What version is it?
What architecture is the machine doing the build?

-- 
Robert Kern



More information about the SciPy-User mailing list