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

[Rob Hetland]

I found that I needed to simlink

/usr/lib/gcc/i686-apple-darwin8/4.0.1/libgcc.a -> /usr/local/lib/ 
libcc_dynamic.a

(Similar to the previous PPC gcc4 instructions.)  That fixes the  
missing cc_dynamic library problem for me.

-Rob



On Apr 7, 2006, at 4:48 PM, Robert Kern wrote:

> 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
>
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user

-----
Rob Hetland, Assistant Professor
Dept of Oceanography, Texas A&M University
p: 979-458-0096, f: 979-845-6331
e: hetland at tamu.edu, w: http://pong.tamu.edu