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

Re: 980201: NetCDF problems w/Linux

>From: Greg Fall <address@hidden>
>Subject: NetCDF problems w/Linux
>Organization: University of Michigan?
>Keywords: 199802010159.SAA05810 netCDF Linux

Hi Greg,

> Tried to build NetCDF today a few times on my Linux (kernel 2.0.32)
> system.  Started with version 3.4a, then tried 3.3.1, than 2.4.3.
> 
> The build went fine in every case.  However, whenever I tried to use
> ncdump on one of my data files, I'd get errors.
> 
> With versions 3.4a and 3.3.1, the error looks like this:
> 
>     bash % ./ncdump /mnt/zip/HRDI/ng_0094_v1_2.nc 
>     ./ncdump: /mnt/zip/HRDI/ng_0094_v1_2.nc: Invalid argument

After you built netCDF, did you run "make test" to see if it passed all
the tests that come with the source distribution?  In particular, did
the ncdump test work?

I'd like to find out if the problem is specific to your netCDF file or
Linux systems.  There are lots of netCDF users on Linux systems, but
this is the first report of this sort of problem.  The fact that version
2.4.3 gets a possibly unrelated error on a PC is not of much use to us,
since we would have difficulty reproducing the problem here, but we do
have a Linux platform.  If "make test" seems to work, could you make
available to us a netCDF file with which you see an ncdump failure?  I
can grab it via FTP if you can put it on a server there, or maybe you
can come up with an example that's small enough to mail uuencoded or in
some other mailable form for binary files (e.g. base-64).

> I went to my research group's VMS machine, on which version 2.4.3 is
> built, and tried ncdump on the same file.  No problems.  So I built 2.4.3
> on my PC, and the error ncdump gives me is now
> 
>     bash % ./ncdump /mnt/zip/HRDI/ng_0094_v1_2.nc
>     ncopen: string length 3183 exceeds 128
> 
> Apparently the same problem.

I'm not sure this is the same problem.  In any case, I'd like to find
the bug using the current version, since we no longer maintain version
2.4.3. 

> Hacked around in version 3.3.1, and found that the problem is this:
> do_ncdump (in ncdump.c) is executed.  It calls nc_open (in nc.c), which
> calls nc_get_NC (in v1hpg.c).  nc_get_NC gets to this point:
> 
>       status = v1h_get_NC_attrarray(&gs, &ncp->attrs);
>       if(status != ENOERR)
>               goto unwind_get;
> 
> and jumps to the unwind_get tag after executing the v1h_get_NC_attraray
> routine.  v1h_get_NC_attraray gets this far:
> 
>       if(type != NC_ATTRIBUTE)
>               return EINVAL;
> 
> Hope that's informative.  Thanks for any help you can give me.
> 
> - - Greg
> 
> - ----------------------------------------------------------------
> 
> Here's the top of my configure file for versions 3.3.1 and 3.4a:
> 
> CPPFLAGS=-Df2cFortran
> CC=/usr/bin/cc
> CFLAGS=-g
> FC=/usr/bin/fort77
> FFLAGS='-g -Nx400 -w'
> CXX=/usr/bin/c++
> FPPFLAGS=${FPPFLAGS-}
> 
> And here is the output of the configure script:
> 
> bash % ./configure
> loading cache ./config.cache
> checking for m4... (cached) m4
> checking user-defined C compiler "/usr/bin/cc"
> checking C compiler... works
> checking how to make dependencies... false
> checking for /usr/bin/c++... (cached) /usr/bin/c++
> checking C++ compiler "/usr/bin/c++"... works
> checking how to run the C preprocessor... (cached) /usr/bin/cc -E
> checking user-defined FORTRAN compiler "/usr/bin/fort77"... works
> checking for FORTRAN .F compiler... 
> checking if FORTRAN compiler handles *.F files... yes
> checking for C-equivalent to FORTRAN routine "SUB"... sub_
> checking for FORTRAN "byte"... yes
> checking for FORTRAN "integer*2"... yes
> checking if FORTRAN "byte" is C "signed char"... yes
> checking if FORTRAN "byte" is C "short"... no
> checking if FORTRAN "byte" is C "int"... no
> checking if FORTRAN "integer*2" is C "short"... yes
> checking if FORTRAN "integer*2" is C "int"... no
> checking if FORTRAN "integer" is C "int"... yes
> checking if FORTRAN "real" is C "float"... yes
> checking if FORTRAN "doubleprecision" is C "double"... yes
> checking for FORTRAN-equivalent to netCDF "byte"... byte
> checking for FORTRAN-equivalent to netCDF "short"... integer*2
> checking for math library
> checking for -lc... (cached) no
> checking for -lm... (cached) yes
> checking for ar... (cached) ar
> checking for ranlib... (cached) ranlib
> checking for stdlib.h... (cached) yes
> checking for sys/types.h... (cached) yes
> checking for strerror... (cached) yes
> checking for ftruncate... (cached) yes
> checking for st_blksize in struct stat... (cached) yes
> checking whether cross-compiling... (cached) no
> checking for IEEE floating point format... yes
> checking for ANSI C header files... (cached) yes
> checking for size_t... (cached) yes
> checking for off_t... (cached) yes
> checking for ssize_t... (cached) yes
> checking for ptrdiff_t... (cached) yes
> checking for uchar... (cached) no
> checking whether char is unsigned... (cached) no
> checking whether byte ordering is bigendian... (cached) no
> checking size of short... (cached) 2
> checking size of int... (cached) 4
> checking size of long... (cached) 4
> checking size of float... (cached) 4
> checking size of double... (cached) 8
> checking size of off_t... (cached) 4
> checking size of size_t... (cached) 4
> checking for manual-page index command... 
> checking binary distribution directory...
> /home/ftp/pub/binary/dummy_system
> creating ./config.status
> creating macros.make
> udcreating fortran/nfconfig.inc
> fortran/nfconfig.inc is unchanged
> creating libsrc/ncconfig.h
> libsrc/ncconfig.h is unchanged