[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
970204: Netcdf under NeXTstep
- Subject: 970204: Netcdf under NeXTstep
- Date: Tue, 04 Feb 97 10:53:26 -0700
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>