[SciPy-user] SciPy with gcc4 and gfortran on OS X
zpincus at stanford.edu
Fri Apr 7 17:05:09 CDT 2006
Thanks for your quick reply.
>> 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':
>> return opt
>> so that the unnecessary cc_dynamic library was not included.
> That's reasonable, yes.
Presumably a fix along these lines should go into the numpy svn?
>>> In : import scipy
>>> import linsolve.umfpack -> failed: No module named _umfpack
> This has nothing to do with gfortran. The linsolve setup.py is
> screwy and is
> building __umfpack.so instead of _umfpack.so.
Aah, OK. Presumably I should just sit tight and this will get
resolved at some point? Or can I help track down the problem in any
way? (It doesn't really affect me, so no matter.)
>>> 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.
I thought I had seen something, so some searching turned up a March 7
email by Neil Becker to scipy-dev (subject "[PATCH] d1mach problem")
which has a patch to make d1mach compile with -O0. I'll try out this
patch (and a version with -O) and let you know if it works. Neil also
had to patch numpy/distutils/command/build_clib.py to allow
'extra_postargs' to be passed through to the fortran compiler.
Anyhow, I'll report on the success of these patches. If they work, is
this something that should or should not go into scipy, do you think?
(If they do go in, a bug ticket should be filed about not using -O2
so that this vaguely ugly hack gets revisited if/when gfortran gets
More information about the SciPy-user