[SciPy-dev] Re: scipy / SGI MIPSpro compiler (part 3)
pearu at scipy.org
Mon Aug 26 13:25:08 CDT 2002
On Mon, 26 Aug 2002, Steve M. Robbins wrote:
> I'll try to rebuild scipy using SGI f77. I thought it would be enough
> to just remove these lines from scipy/setup.py:
> # force g77 for now
> -from scipy_distutils.command import build_flib
> -build_flib.all_compilers = [build_flib.gnu_fortran_compiler]
> After doing so, I was able to build scipy using f77. But it
> didn't link properly, I suppose:
> >>> import scipy
> /home/bic/stever/irix-6/lib/python2.1/site-packages/scipy/linalg/lapack.py:24: UserWarning: exceptions.ImportError: No module named clapack
> exceptions.ImportError: No module named cblas
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> File "/usr/local/unstable/lib/python2.1/site-packages/scipy/__init__.py", line 62, in ?
> import optimize, integrate, signal, special, interpolate, cow, ga, cluster, weave
> File "/usr/local/unstable/lib/python2.1/site-packages/scipy/integrate/__init__.py", line 31, in ?
> from quadpack import *
> File "/usr/local/unstable/lib/python2.1/site-packages/scipy/integrate/quadpack.py", line 4, in ?
> import _quadpack
> ImportError: 60347:python: rld: Fatal Error: unresolvable symbol in /home/bic/stever/irix-6/lib/python2.1/site-packages/scipy/integrate/_quadpack.so: ddot_
> Pearu: are there other tricks needed to build with SGI cc & SGI f77?
I didn't use any additonal tricks. When rebuilding, make sure that you
rm -rf build
Now I see that integrate module uses atlas and it does not check if there
is no atlas available. It should then try also blas libraries... I'll fix
As a quick workaround, you can copy the required (e.g. all) blas sources
to integrate/linpack_lite directory and rebuild.
> > Could you try out the following scripts:
> [ ... ]
> > I hope that the first one prints `9' and the second one prints some
> > nonsense.
> Yes, they do when using g77. But it is the other way around (first is
> nonsense, second prints '9') when using f77. That sounds like a
> nightmare to support.
Indeed. I need to think about this more. At least now I don't see a way
how f2py should know how external libraries are built, in particular,
which compilers were used. Because from this information the corresponding
wrapper should be constructed. However, when using Fortran wrappers around
Fortran functions, there should be no issue at all -- calling Fortran
subroutines from C is not that compiler dependent as calling Fortran
More information about the Scipy-dev