Floating pnt upgrade on SGI - recompile trouble

[Peter Briggs]

I wrote:

>>Hi, I'm trying to compile the floating point upgrade on our SGI Indigo2
>>(R4400 chipset).  When I ran GISGEN it got as far as front.end and died.
>>Olga kindly provided part of the solution--that the gis library was not
>>recompiling. I removed all the .o files in src/libes/gis and recompiled with
>>gmake4.1.  Resuming GISGEN got me as far as d.display.  I then recompiled
>>everything in the src/libes/* directories but GISGEN still falls down at
>>d.points, unable to resolve 'region'.  

You wrote:

>Maybe you just don't have the correct libes/gis/sites.c file
>(I noticed it was missing from the tar file)
>Please substitute your libes/gis/sites.c with the included file.
>Sorry for the delayed reply!
>Olga

My turn:

Hi Olga, I've been operating with your Jan. 16 fp/null upgrade now (which
solved some of the problems I first wrote about) and have tried the
following configurations:

1)  With the Jan. 16 sites.c and the addition of the line DATETIMELIB =
/usr/lib/libc.so.1 to make.mid, the compilation appears to work except for
the following hitches:

----At g.help...(This was not fatal to GISGEN)
ld: The shared object /usr/lib/libm.so did not resolve any symbols.  
----At r.coin and r.neighbors...(Not fatal to GISGEN)
The shared object /usr/lib/libtermlib.so did not resolve any symbols.
----At v.in.tig.lndmk (which I just skipped)...
make: file `OBJ.sgi/make.rules' line 143: Syntax error
GISGEN failure at STEP: src.alpha/mapdev/v.in.tig.lndmk
----At r.surf.contour (which I just skipped)...
ld:  Unresolved:  log    *** Error code 1 (bu21)
----Dtrue and SG3d also failed but I gather from the recent exchanges with
Matthew Mellon that this can be sorted out.  

2)  If I use the Macauley sites.c file you sent me and DATETIMELIB =
/usr/lib/libc.so.1 in make.mid I get the following crash at d.sites,
g.region, v.mkquads, p.map, r.random, r.volume, s.in.ascii, s.out.ascii,
s.surf.idw, v.to.sites, p.map.new, ps.map, and s.surf.tps:

ld:
Unresolved:
datetime_format
datetime_scan
datetime_error_msg
*** Error code 1 (bu21)
*** Error code 1 (bu21)

as well as the same problems with v.in.tig.lndmk and r.surf.contour as above.

3)  If I **don't** use DATETIMELIB = /usr/lib/libc.so.1 in make.mid I get
the following crash at d.sites, g.region, s.in.ascii, s.out.ascii,
s.surf.idw (with variations in the line number of the error)

make: file `OBJ.sgi/make.rules' line 139: Syntax error
*** Error code 1 (bu21)

but I get the same error as in number 2 above for the other routines listed,
and the same errors with v.in.tig.lndmk and r.surf.contour as in 1.

In the case of all three compilation strategies above, I get the
segmentation fault with r.in.ascii at run time.  I'll send you a copy of a
dataset which produces this shortly.


My inference from all this is that

a) The sites.c in your Jan. 16 fp/null update may be better than the sites.c
you just sent me.
b) The problems I'm having seem to be due in the first case to DATETIMELIB
not being assigned, and in the second case to the possibility that setting
DATETIMELIB = /usr/lib/libc.so.1 in make.mid isn't the way to solve this
properly (it was just a guess).
c) The errors with r.surf.contour and v.in.tig.lndmk are unrelated to the
others.


>>I am sorry for the problems you are having, it is very hard
>>to include all the new things in one .tar file.

It defies description how grateful we all are for the effort and patience
you and the CERL crowd put in to help solve problems like this.  So forget
it :-)

And thanks, Peter Briggs 

-------------------------------------------------------------------------
CSIRO Centre for Environmental Mechanics
GPO Box 821, Canberra, ACT 2601, Australia
ph:  +61 6 246 5554   fax:  +61 6 246 5560
email:  pbriggs at enmech.csiro.au
http://www.enmech.csiro.au/pyelab/people/pbcv.htm