On Thu, 2007-01-25 at 02:37 +0000, Glynn Clements wrote:
Brad Douglas wrote:
> > Does that mean that i.fft and i.fft will not build or work properly
> > using gfortran coming with GCC 4.0.3? Is that an issue only with 64 bit
> > systems?
>
> It's a GCC issue. If you want i.fft/i.ifft, you need LAPACK/BLAS
> support,
No you don't. i.fft and i.ifft require FFTW, but they don't require
LAPACK/BLAS. Nothing in GRASS currently requires BLAS/LAPACK.
Copying thread to devel and changing subject...
Oops! I should have checked before I wrote. Yes, FFTW is required, not
BLAS/LAPACK.
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.
Thanks!
--
Brad Douglas <rez touchofmadness com> KB8UYR/6
Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785
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.
> > > Does that mean that i.fft and i.fft will not build or work properly
> > > using gfortran coming with GCC 4.0.3? Is that an issue only with 64 bit
> > > systems?
> >
> > It's a GCC issue. If you want i.fft/i.ifft, you need LAPACK/BLAS
> > support,
>
> No you don't. i.fft and i.ifft require FFTW, but they don't require
> LAPACK/BLAS. Nothing in GRASS currently requires BLAS/LAPACK.
Copying thread to devel and changing subject...
Oops! I should have checked before I wrote. Yes, FFTW is required, not
BLAS/LAPACK.
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)?
The alternatives are:
1. Use gcc 3.x.
2. Figure out how to call Fortran from C with gcc 4.x without any help
from the gcc developers.
Regarding #1: if the Fortran changes between 3.x and 4.x are
significant, you may also have to compile BLAS/LAPACK with 3.x.
> 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.