[GRASS-dev] Re: BLAS/LAPACK

[Glynn Clements]

Hamish wrote:

> > I do have a few imagery modules I want to finish, but I moved on to
> > something else once BLAS/LAPACK became an issue.  I've implemented a
> > few more routines for the imagery spectral modules, but it was
> > problematic. What are the alternatives, other than very, very
> > patiently waiting for gcc4 to catch up (this will be some time from
> > what I have gathered from the gcc mailing lists)?
> > 
> > Forcing users to compile with gcc3.x in order to gain functionality is
> > not my idea of usability.  IIRC, gcc3.x doesn't support macros for
> > multi-core CPU ops, which have been implemented in lib/gpde.  They
> > will be safely ignored in gcc3.x, but it would be nice.
> 
> (with sincere apologies to RMS)
> 
> does it need a functional Fortran compiler, or a functional gcc f2c?
> 
> Other (non-Free) Fortran compilers do exist for Linux, and some of them
> do work very nicely..... could the gcc4.x C compiler be used with e.g.
> ifc, until the day gcc-F gets fixed? Then GRASS -dev is not stalled due
> to 3rd party/sole-supplier problems.

The problem is that gcc 4.x doesn't include g2c.h (or any equivalent),
so blas.h and lapack.h won't compile due to the missing types.

The larger problem is that the brand new Fortran support in gcc 4.x
appears to be essentially undocumented, so it's by no means clear how
to call Fortran functions from C.

If the calling convention remains unchanged (I have no idea if it has
or hasn't), then it's just a matter of defining the types which blas.h
and lapack.h use, i.e.:

	L_fp
	char
	complex
	doublecomplex
	doublereal
	ftnlen
	integer
	logical
	real
	void

OTOH, if the calling convention has changed, then blas.h and lapack.h
need to be re-written.

-- 
Glynn Clements <glynn at gclements.plus.com>