[SciPy-dev] Re: scipy / SGI MIPSpro compiler (part 3)

[Pearu Peterson]

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]

Yes.

> 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
>   warnings.warn(clapack.__doc__)
> 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   
also do
 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 
it later.
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 
functions.

Pearu