Known Problems with the netCDF Distribution 2.4.2

Unidata - To provide the data services, tools, and cyberinfrastructure leadership that advance Earth system science, enhance educational opportunities, and broaden participation.

DataToolsCommunityDownloadsSupportProjectsAbout Us

•

Known Problems with the netCDF Distribution

This is where we document some reported problems with the current release (netCDF version 2.4.2) and their workarounds.

Building on Windows NT
Building on IRIX 6.2
Long strings and ncgen
Record strings and ncgen

Building on Windows NT

Problem: the current instructions for building from source under Windows NT are missing a couple of steps.

Before building:

copy local_nc.gen to local_nc.h in the libsrc directory
copy msoftyy.c to ncgenyy.c and copy msofttab.h to ncgentab.h in the ncgen directory

Building on IRIX 6.2

Problem: the current netCDF distribution compiles on IRIX 6.1 but not on IRIX 6.2. When the `configure' script checks the XDR library, it reports:

  checking XDR library for xdr_getint()... yes

but it should get "no" for this, because SGI removed this function from a structure between IRIX 6.1 and 6.2. Later this error is manifested when compiling:

        c89 -c -O  xdrposix.c
cfe: Error: xdrposix.c, line 312: 'x_getint' undefined; reoccurrences will not b
e reported.
            xdrposix_ops.x_getint = xdrposix_getint;
        ----------------^

This is fixed in the next release, but for now try the following workaround:

Delete the following lines from the "configure" script:

   irix64)
       echo "$ac_t""yes" 1>&6
       HAS_XDR_GETINT=1;;

Run "make clean".
Run the "configure" script with whatever arguments you used before.
Run "make all", then "make test", then optionally "make install".

The "fixed" configure script will no longer work for IRIX 6.1, so if you need to build the package on that OS, you should save the old version.

Long strings and ncgen

When reading a very long string in a CDL file, ncgen emits an error message about a "parse error" or "syntax error" (depending on which platform ncgen is invoked from).

This error comes from the "lex" utility used to generate ncgenyy.c from ncgen.l. The "lex" program builds parsers that can't handle lines longer than 1024 characters. This limit may be different for "lex" on different platforms. If you split the CDL data statement, e.g.:

   stringvar = "000...000" ;  // 1440 zeros

into something like the following instead:

   stringvar = "000...000",   // 1000 zeros
           "000...000" ;  //  440 zeros

then the lex limit will not be encountered. Since we can't change lex, it looks like fixing this will require making "ncdump" output substrings that don't exceed the built-in lex limit.

Record strings and ncgen

The following tiny CDL file demonstrates a bug with ncgen:

    netcdf bug {
    dimensions:
        time = UNLIMITED ;
    variables:
        char var(time) ;
    data:
        var = "abcd";
    }

Running ncgen on the above CDL file produces the error message:

    ncgen: var.cdl line 7: string won't fit in this variable, 4>1

The problem is with character variables that use only the record dimension, such as the variable "var" above. The above works fine with ncgen when the character string is separated into individual characters, as in:

    netcdf bug {
    dimensions:
        time = UNLIMITED ;
    variables:
        char var(time) ;
    data:
        var = "a", "b", "c", "d";
    }

The next release will fix the way ncdump outputs such variables as well as the way ncgen parses the old ncdump output.

In the meantime, ways to avoid this bug are to use NC_BYTE instead of NC_CHAR types for 8-bit values that vary only along the record dimension, or to separate the output of ncdump for such variables into individual characters for each record.

				Unidata is a member of the UCAR Office of Programs, is managed by the University Corporation for Atmospheric Research, and is sponsored by the National Science Foundation.
				P.O. Box 3000 • Boulder, CO 80307-3000 USA • Tel: 303-497-8643 • Fax: 303-497-8690