Re: netcdf install problems

> Organization: Cray Computer Corporation
> Keywords: 199403162311.AA09422

Hi Dave,

> I was given this mail address by John Truesdale at NCAR.  
> 
> I am trying to install netcdf on the Cray-3 system at NCAR.  The build went 
> fine, but I then attempted to run "make test" as the install documentation 
> suggested.  That failed with the following errors:
> 
> 
> 
> - ------------------------ begin included text -------------------
> # make test
>  
> making `test' in directory /usr/tmp/resch/netcdf/netcdf-2.3.2/fortran
> making `test' in directory /usr/tmp/resch/netcdf/netcdf-2.3.2/xdr
> making `test' in directory /usr/tmp/resch/netcdf/netcdf-2.3.2/nctest
>  
> making `test' in directory /usr/tmp/resch/netcdf/netcdf-2.3.2/libsrc
>  
>         ./nctest
>         /u0/cs/bin/cc -c  -DNETLONG=int -DNDEBUG  cdftest.c
>         ./xdrtest > xdrtest_out.new
>         ar rcuv libnetcdf.a array.o attr.o cdf.o dim.o file.o iarray.o 
> error.o  globdef.o putget.o putgetg.o sharray.o string.o var.o  xdrposix.o
>         ar rcuv ../libsrc/libnetcdf.a jackets.o
>         ./fortc -L . -O csos ftest.src > ftest.f
> *** Testing nccreate ...        ok ***
> *** Testing ncopen ...          diff xdrtest_out.new testout.sav
> *** test_ncopen: ncendef failed after ncattput
> *** XDR passes formatted test ***
> cmp test.xdr test_xdr.sav
> ar: phase error on xdrstdio.o
> Make: "ar rcuv libnetcdf.a array.o attr.o cdf.o dim.o file.o iarray.o error.o 
>  globdef.o putget.o putgetg.o sharray.o string.o var.o  xdrposix.o": Error 
> code 1
>  
> test.xdr test_xdr.sav differ: char 3477, line 1
> *** XDR fails binary test ***
> Make: "cmd="cmp test.xdr test_xdr.sav"; \
> echo $cmd; \
> if $cmd; then \
>     echo "*** XDR passes binary test ***"; \
> else \
>     echo "*** XDR fails binary test ***"; \
>     exit 1; \
> fi": Error code 1
>  
> Make: "dir=`echo xdr/test | sed 's,/.*,,'`; \
>     target=`echo xdr/test | sed "s,$dir/,,"`; \
>     cd $dir && \
>     echo "making \`$target' in directory `pwd`" && \
>     echo "" && \
>     make  CC="/u0/cs/bin/cc"  CPP="/lib/cpp"  exec_prefix="/usr/local/bin"  
> FC="f77"  prefix="/usr/local" \
>         prefix=/usr/local exec_prefix=/usr/local/bin \
>         $target || exit 1": Error code 1
>  
> `test' not remade because of errors
> Process failed, waiting for current processes.

This output is fairly incomprehensible, because it apparently is produced by
several parallel makes running at the same time with their outputs
interspersed.  If you could turn off the parallel make option and have this
run serially, it would make debugging the problem simpler.  There is no
purpose in running "make test" in any of the other subdirectories if "make
test" fails in the xdr directory, because if the XDR test fails, the other
tests will also likely fail.  The "make test" targets are designed to run in
a certain order from simpler to more comprehensive, with each test depending
on the success of previous tests.

> I then went ahead and installed the binaries, etc in /usr/local and tried
> to run ncdump on an existing .cdf file.  It appears that integers, longs,
> etc are interpreted correctly, but floating point numbers do not seem to
> get interpreted correctly.  Here is a portion of that output:

If the "make test" fails in any of the subdirectories in which it is run
(xdcr, libsrc, nctest, fortran, ncdump, ncgen), there is not much use
installing any binaries until the problems are diagnosed and fixed.
Apparently the first problem occurs in testing the XDR library, so there may
be a problem in the XDR encoding of floating-point numbers, enums, or some
other kinds of data values.  Since the formatted XDR test works, apparently
the Cray 3 can read back what it has written with the XDR encoding, but that
doesn't mean that any other machine can read the Cray 3-created XDR file.
This points to a bug in the XDR library you are using.  I assume you are
using the Cray XDR library, rather than the generic one we supply, which
probably wouldn't work for the Cray 3 architecture.

The binary XDR test that fails is comparing the Cray 3-created XDR file with
an XDR file created on a different platform that should be identical.  If
you can find out where the difference is, you can determine which type of
value is not getting encoded properly.

> test.xdr test_xdr.sav differ: char 3477, line 1
> *** XDR fails binary test ***

This difference is not very far into the XDR file, but I can't tell from
this position in the file what value was being written.  If you look at the
xdrtest.c program, you may be able to figure out where this is, or you can
read the resulting XDR file on another platform and print out what is read
to find out where things are going wrong.

__________________________________________________________________________
                      
Russ Rew                                              UCAR Unidata Program
address@hidden                                        P.O. Box 3000
(303)497-8645                                 Boulder, Colorado 80307-3000