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

[Steve M. Robbins]

On Mon, Aug 26, 2002 at 03:22:19AM -0500, Pearu wrote:

> I have succesfully (without any errors except from weave) tested scipy on 
> the following platform:
> 
> bash$ python -c 'import os,sys;print os.name,sys.platform'
> posix irix646

ditto

> bash$ uname -a
> IRIX64 ape 6.5 07201608 IP30

IRIX64 wart 6.5 10100655 IP27 mips

> bash$ python -c 'import sys;print sys.version'
> 2.1.1 (#1, Oct 21 2001, 16:10:39) [C]

2.1.3 (#3, Aug 24 2002, 13:12:16) [C]

> bash$ python -c 'import Numeric;print Numeric.__version__'
> 20.2.1

21.0


> bash$ cc  -version
> MIPSpro Compilers: Version 7.30
> bash$ f77 -version
> MIPSpro Compilers: Version 7.30
> bash$ 

ditto, except scipy used GNU fortran:

  swmgr at wart{f77}g77 --version
  GNU Fortran (GCC 3.2) 3.2 20020814 (release)


> where both LAPACK and BLAS are built by scipy, in the lines of the 
> following:
> 
> cd scipy
> LAPACK_SRC=/path/to/src/lapack BLAS_SRC=/path/to/src/blas \
>  python setup.py build
> 
> Do you see any difference with your case?

I have a slightly newer python, slightly newer Numeric, and used the
GNU Fortran compiler.


> Did you build LAPACK/BLAS 
> yourself (then how? compiler flags?) or did you let scipy to build them 
> as above? Btw, what is the output of

I let scipy build LAPACK and BLAS by editing site.cfg.


>  python scipy_distutils/system_info.py


atlas_info:
  NOT AVAILABLE

blas_info:
  NOT AVAILABLE

blas_src_info:
  FOUND:
    sources = ['../../numerical/blas/caxpy.f', '../../numerical/blas/cssca ...
... /../numerical/blas/zsymm.f', '../../numerical/blas/ztrsm.f']

dfftw_info:
  NOT AVAILABLE

dfftw_threads_info:
  NOT AVAILABLE

djbfft_info:
  NOT AVAILABLE

fftw_info:
  NOT AVAILABLE

fftw_threads_info:
  NOT AVAILABLE

lapack_info:
  NOT AVAILABLE

lapack_src_info:
  FOUND:
    sources = ['../../numerical/LAPACK/SRC/sbdsdc.f', '../../numerical/LAP ...
... LAPACK/SRC/izmax1.f', '../../numerical/LAPACK/SRC/dzsum1.f']

sfftw_info:
  NOT AVAILABLE

sfftw_threads_info:
  NOT AVAILABLE

x11_info:
  NOT AVAILABLE


 
> in your case (with all enviroment variables like LAPACK_SRC, BLAS_SRC,
> etc set)? Do you have any system blas/lapack installed?

No lapack, but there is /usr/lib/libblas.  Unfortunately, it is
an o32 binary so I had to trick scipy into NOT using it with

    [blas]
    # dummy value to force building from blas_src
    blas_libs = nonexistant

in site.cfg.


> I am asking this information because it is possible that your Fortran
> compiler assumed that Fortran "real" is "real*8" but f2py assumes
> "real*4". See if you can find any relevant flags in your compiler manual.

As far as I can tell, GNU Fortran treats "real" as "real(kind=1)".
The latter is defined to be the same size as a float (4 bytes).

However, there is an interesting note in the section on interoperating
with C/C++ 

 http://gcc.gnu.org/onlinedocs/gcc-3.2/g77/Interoperating-with-C-and-C--.html

    A simple and foolproof way to write g77-callable C
    routines--e.g. to interface with an existing library--is to write
    a file (named, for example, fred.f) of dummy Fortran skeletons
    comprising just the declaration of the routine(s) and dummy
    arguments plus END statements. Then run f2c on file fred.f to
    produce fred.c into which you can edit useful code, confident the
    calling sequence is correct, at least. (There are some errors
    otherwise commonly made in generating C interfaces with f2c
    conventions, such as not using doublereal as the return type of a
    REAL FUNCTION.)

    f2c also can help with calling Fortran from C, using its -P option
    to generate C prototypes appropriate for calling the Fortran.  If
    the Fortran code containing any routines to be called from C is in
    file joe.f, use the command f2c -P joe.f to generate the file
    joe.P containing prototype information. #include this in the C
    which has to call the Fortran routines to make sure you get it
    right.


Using the following input

      real function quibit(x)
      real x
      quibit = x
      end

I ran "f2c -P" to find the C prototype, and it came back as

    extern E_f quibit_(real *x);

Maybe that's a clue?  [I'm afraid, though, I'm pretty clueless
when it comes to Fortran]


Regards,
-Steve