[GRASS5] Problems compiling r.fill.dir

[Roger Bivand]

On Tue, 3 Apr 2001, Roger S. Miller wrote:

> Malcolm Blue wrote:
> > 
> > Fortran programmers,
> > 
> > It's been a long time since I've done any fortran programming.  The
> > compile for r.fill.dir exits with the following error messages:
> 
> Malcom,
> 
> These look like some ugly problems.  I think the version of r.fill.dir
> now in the CVS tree is the one that I hacked to use floating point
> elevations.  It compiled without problems on i586-pc-linux and ran fine
> for me, but not well for Markus.  Markus since asked Huidae Cho to look
> into the problems, because I pretty much ran out of time.
> 
> The cygwin port of g77 must be more exacting than my linux port when it
> comes to COMMON blocks.  The problem appears to be with the LEVEL
> array.  In the original source code I think it was declared as REAL *2
> LEVEL(4002,3).  I changed that to DOUBLE PRECISION LEVEL(4002,3) in all
> of the subroutine where LEVEL was used, but apparently didn't change it
> in those subroutine where it wasn't referenced.  One of the blank COMMON
> statements excludes LEVEL entirely, which may be a feature of the
> original code.
> 
> > There are a number of messages of the same type.  Is it possible to
> > reorder the variables on the common blocks defined in r.fill.dir, or is
> > there a switch to g77 that will tell it to align members of a common
> > block to the same byte length?
> 
> I don't know if g77 has a switch that relaxes it's restrictions on blank
> COMMON.  Unfortunately my server at work seems to be off line and I
> can't reach my sources or the documentation.  I got the ppupdate.f
> source in the CVS tree and it looks like it may be sufficient to just
> make a few changes.
> 
> LEVEL is declared as INTEGER *2 in subroutines PATH, FIXALOOP, UPDATE,
> and DOMAPTO.  In each case the source may need to declare LEVEL as
> DOUBLE PRECISION.  Additionally, subroutine FILL doesn't declare LEVEL
> at all and it may be necessary to add it's declaration (as DOUBLE
> PRECISION) to that subroutine.
> 
> If your g77 insists on having the large variable declared first, then
> you can probably change their order.  The change needs to be made in all
> of the "COMMON MASK,LEVEL" statements.  Change them to "COMMON
> LEVEL,MASK".  In addition, the DO3BY3 subroutine declares the block as
> "COMMON MASK,ELEV" and this needs to be changed to "COMMON ELEV,MASK". 
> In fact, it might be necessary to rename ELEV to LEVEL in that
> subroutine. 
> 
> > 
> > Any other suggestions?
> 
> If you don't need r.fill.dir right away, then hold off on trying to fix
> it.  I'm converting the source to C and that should be ready in a few
> weeks, depending on how much time I have available to work on it. 
> Huidae Cho may also be working on the source.  If you do need it right
> away then I can probably send you a copy with the changes I described
> above.
> 
> 
Two suggestions: avoid unnamed commons - because they may actually be
different in different subroutines(!), and secondly put commons with their
declarations in a separate file, such as tbl.cmn, and include them in the
[fg]77 source:
      include 'tbl.cmn'

Then all the subroutines get the same declarations, and you reduce the
risk of typos. Think of them as structures declared in C header files,
just that they can't be addressed as structures.

Finally, I like implicit logical(a-z), because it flags most bugs in
declarations so neatly, but can be tedious in legacy code.

The g77 info suggests that one doesn't try to suppress these kinds of
warnings, alignment in commons does matter, and sometimes it is even worth
declaring unused variables in the common to get the alignment right.

Roger

-- 
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand at nhh.no
and: Department of Geography and Regional Development, University of
Gdansk, al. Mar. J. Pilsudskiego 46, PL-81 378 Gdynia, Poland.


---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'