[SciPy-user] SciPy with gcc4 and gfortran on OS X

[Robert Kern]

Zachary Pincus wrote:
> Hi folks,
> 
> Emboldened by the some reported successes with compiling SciPy with  
> gfortran and gcc4 on OSX/Intel machines, I thought I'd give it a try  
> on my powerbook.
> 
> Unfortunately, it did not work -- but hopefully it's close, because  
> the problems I saw are all things that various people on this list  
> have seen and solved.
> 
> VITALS
> OS X 10.4.6, on a PPC G4
> gcc: powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer,  
> Inc. build 5250)
> gfortran: GNU Fortran 95 (GCC) 4.2.0 20060218 (experimental)
> (gfortran binary downloaded from hpc.sf.net today.)
> SVN checkout of numpy and scipy from today.
> 
> BUILD PROBLEM
> I only had one problem during the build -- there were errors like:
>   /usr/bin/ld: can't locate file for: -lcc_dynamic
> I fixed this by modifying numpy/distutils/fcompiler/gnu.py so that  
> the Gnu95FCompiler class had a method like:
>      def get_libraries(self):
>        opt = GnuFCompiler.get_libraries(self)
>        if sys.platform=='darwin':
>          opt.remove('cc_dynamic')
>        return opt
> so that the unnecessary cc_dynamic library was not included.

That's reasonable, yes.

> RUNTIME PROBLEMS
> 
>>In [1]: import scipy
>>import linsolve.umfpack -> failed: No module named _umfpack
> 
> I think that people had seen this problem before, but using a more  
> recent gfortran solved it for them on intel macs. I'm using the most  
> recent gfortran from hpc.sf.net on my G4, so this problem still  
> persists.

This has nothing to do with gfortran. The linsolve setup.py is screwy and is
building __umfpack.so instead of _umfpack.so.

>>In [2]: scipy.test()
>>import linsolve.umfpack -> failed: No module named _umfpack
>>Overwriting fft=<function fft at 0x284f570> from  
>>scipy.fftpack.basic (was <function fft at 0x1395930> from  
>>numpy.dft.fftpack)
>>Overwriting ifft=<function ifft at 0x284f5f0> from  
>>scipy.fftpack.basic (was <function inverse_fft at 0x1395970> from  
>>numpy.dft.fftpack)
> 
> ...
> 
>>Adjust D1MACH by uncommenting data statements
>>appropriate for your machine.
>>STOP 779
> 
> Also a problem people had seen with gfortran, but one that I thought  
> had been patched.

No patch has been submitted. I believe that the solution is to compile d1mach.f
with -O only and not -O2. Possibly also the -ffloat-store flag needs to be set
as well.

-- 
Robert Kern
robert.kern at gmail.com

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco