[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

970204: Netcdf under NeXTstep

Steve,

>Date: Mon, 3 Feb 1997 20:33:26 -1000 (HST) 
>From: Steven Howell <address@hidden>
>Organization: University of Hawaii
>To: Russ Rew <address@hidden>,
>To: Steve Emmerson <address@hidden>
>Subject: Re: 970130: Netcdf under NeXTstep 
>Keywords: 199701310220.TAA15014

In the above message you wrote:

> As Ray suggested, I got netcdf-3.3a from your ftp site. So far, it
> looks much better. I have had some minor problems, and since this is
> a beta version, pehaps you'd like some feedback.

Absolutely!  We appreciate feedback -- it improves the product.

> 1)  When extracting the files from the archive 
>     (zcat netcdf-3.3a.tar.Z | tar xvf -), there was an odd problem
>     with directories that I've never seen before. Each directory was
>     regarded as a zero length executable file rather than a directory.
>     The files that should have gone into the directories couldn't be
>     untarred; I got errors like
>    
>       tar: can't create netcdf-3.3a/src/macros.make.def: Not a directory
>     
>     So, did a tar tf - to get all of the directory names, made those
>     directories by hand, and reran tar, which then complained
>     
>       tar: can't create netcdf-3.3a/src: Is a directory
>     
>     but at least I got all of the files. Could my version of tar be
>     incompatible with yours? Seems unlikely, but I don't know what
>     else would cause that.

Odd problem.  I've never encountered it before (but I've never worked on
a Next before either).  We try to make the tar(1) files as portable as
possible, so I'm a little suspicious of your tar(1) but, we'll have to
look into it.

> 2)  INSTALL mentions a README file, which isn't in the distribution.

Oops!  We don't have one either.  We'll have to create it.

> 3)  I set the following environment variables:
>     
>       setenv CC cc
>       setenv CFLAGS '-g -Wall -D_POSIX_SOURCE'
>       setenv FC ''
> 
>     configure ran without complaints, but 'make all' failed
>     immediately. Next doesn't supply the dirname utility. Grr. I
>     installed the gnu version, which compiles without problem. Make
>     then choked in the src/fortran directory with the error message
>     
>       Make:  Don't know how to make nextstep.m4.  Stop.

This should be fixed in the next release.

>     For some reason, the macro FC in macros.make wasn't set to the
>     empty string,

If you change the configuration parameters, then you have to `make
distclean' before running the configure script again.

>     which had been the purpose of that last setenv
>     statement (yes, the other setenv statements worked). Instead,
>     macros.make had the line
>     
>       FC              = :
>     
>     which I changed to
>     
>       FC              = 
>     
>     Make all then worked fine, skipping the fortran interface.  The -Wall
>     switch stimulated lots of warning messages.  Most had to do with implicit
>     declarations, variables defined but not used, and useless keywords in 
>     header files.
>     
> 4)  'make test' didn't fare so well, though I'm still optimistic.  
>     libsrc/t_nc and nctest/nctest went fine.  nc_test/nc_test, however
>     had 4 errors, all involving 'uchar', whatever that is:
>     
>       *** Testing nc_get_var1_uchar ... 
>             FAILURE at line 135 of test_get.c: expected: 128, got: 127
>       263 good comparisons. 
>             ### 1 FAILURES TESTING nc_get_var1_uchar! ###
>       
>       *** Testing nc_get_vara_uchar ... 
>             FAILURE at line 854 of test_get.c: value read not that expected
>       263 good comparisons. 
>             ### 1 FAILURES TESTING nc_get_vara_uchar! ###
>       
>       *** Testing nc_get_vars_uchar ... 
>             FAILURE at line 1992 of test_get.c: value read not that expected
>       263 good comparisons. 
>             ### 1 FAILURES TESTING nc_get_vars_uchar! ###
>       
>       *** Testing nc_get_varm_uchar ... 
>             FAILURE at line 3372 of test_get.c: value read not that expected
>       263 good comparisons. 
>             ### 1 FAILURES TESTING nc_get_varm_uchar! ###
>       Total number of failures: 4
>       *** Exit 1
>       Stop.
>       *** Exit 1
>       Stop.
>       *** Exit 1
>       Stop.

Thanks. We'll look into this.

>     I cd'd to ncdump and ran 'make test' which was successful.
>     
>     'make test' in ncgen wasn't so successful.  The first test ( -b ) worked,
>     but the second did not:
>     
>         ./ncgen -c -o ctest0.nc test0.cdl > test0.c
>       cc -o ctest0 -I../libsrc  -DNDEBUG= -O -Wall -D_POSIX_SOURCE  test0.c  
> ../libsrc/libnetcdf.a 
>       ./ctest0                # tests `-c' option, creates ctest0.nc
>       ../ncdump/ncdump -n test1 ctest0.nc > ctest1.cdl
>       52c52
>       <   7, 10000000000, 1.5e+30 ;
>       ---
>       >   7, 10000000000, 1.49999999999999e+30 ;
>       *** Exit 1
>       Stop.
>     
>     If that's just roundoff error, then I'm not too worried about it.
>     
>     Are the errors in nc_test a big problem? If it's a test of the
>     version 3 interface, perhaps it implies that I won't have problems
>     with GMT, which was written with 2.3 in mind.

nc_test tests the version 3 interface.  nctest (no underscore) tests the
version 2 interface.  You *might* be OK.

> Good news!  GMT compiled just fine, and I tested one of the routines that
> depends on a netCDF database.  It worked just fine.  So, aside from the
> failures in nc_test, everything looks good.
> 
> Thanks for your help!

You're welcome.

--------
Steve Emmerson   <address@hidden>