[SciPy-dev] Re: [SciPy-user] Install failure of SciPy
oliphant at ee.byu.edu
Fri Oct 18 20:02:11 CDT 2002
> I hope that after all the trouble, you'll not give up on SciPy, especially
> when I have another bad news about the Intel compiler support.
> First, to fix the above problem, insert the following line
> #define isnan cephes_isnan
> to files
Should this be changed in the source tree. It looks like other
platforms/compilers have an isnan already defined.
> and re-run the build command that should finish now successfully.
> The bad news is that when running scipy tests, it will segfault after
> .Testing ncf
This is definitely a special function problem. This is the "first-place"
in the scipy testing that one calls out to a (hand-wrapped) fortran-compiled special function.
I'm sure the problem is with different linking needs, here.
The special function module needs a c-function to call so that's why f2py
was not used. I'm not sure how to get setup to use the right compiler
switches so that the FORTRAN code called in cdf_wrappers.c works on many
> in the stats module (I have tested it both on suse and debian with
> Intel 5.0 compiler). All other tests from other modules seem to pass fine.
> I am not sure yet what function, even what module exactly, is causing this
> segfault, but it must be either stats or special (as stats uses special).
I'm sure it's special.
Try calling special.ncfdtr all by itself and seeing what happens.
> And both modules cannot be tested locally (special even doesn't have
> working unittests)
Unittests for special are being written as we speak (I've got an undergrad
working on it).
> as they import scipy and that makes finding/fixing bugs
> very time consuming and difficult. I also tried to remove the dependencies
> of these modules on scipy
I don't think stats should ever have dependency on scipy removed (it will
always need special for example).
Special should be able to depend only on scipy_base.
> So, unless someone will figure out quickly the source of this segfault,
> the Intel compiler remains unsupported. But I'll keep looking for the
> solution ...
Again, I think it has to do with magic C-to-Fortran calling conventions
for the Intel compiler.
You will recognize the
#define F_FUNC(f,F) F
#define F_FUNC(f,F) f
#define F_FUNC(f,F) F##_
#define F_FUNC(f,F) f##_
code in the C-wrappers (remember these are not Python wrappers) for the
fortran code in cdflib and specfun.
More information about the Scipy-dev