Known Problems with NetCDF Distributions

This is where we document some reported problems in releases of netCDF, and their workarounds. For more help see the build and test output for netCDF test platforms, the list of other builds of netCDF, and the NetCDF Installation and Porting Guide.

Get the current release of netCDF from the netCDF home page.

Known Problems with netCDF 4.3.0

Known Problems with netCDF 4.2

Known Problems with netCDF 4.1.3

Known Problems with netCDF 4.1.2

Known Problems with netCDF 4.1.1

The clang compiler (default on OSX 10.9 Mavericks) detects error building ncgen3

Building the netCDF C library with the clang C compiler, the default /usr/bin/cc on OSX 10.9 Mavericks, detects an error in compiling ncgen3/load.c. A fix is to insert the line

#include <config.h>
above the "#include <stdlib.h>" statement near the beginning of ncgen3/genlib.h.

This fix will be in the next release.

Fortran options of nc-config utility (--fflags, --flibs, --has-f90) don't work correctly

Beginning with version 4.2 of the C-based netCDF software, the netCDF Fortran library is built from an independent netcdf-fortran release with its own nf-config utility. In netCDF-4.2 the nc-config utility doesn't detect whether nf-config is installed and make use of its output to preserve backward compatibility with nc-config from previous releases. This problem is fixed in netCDF-4.2.1-rc1 and later releases.

Using "--with-hdf5=..." configure option doesn't seem to work

With releases of netCDF-4 after version 4.1.2 (this includes 4.1.3, 4.2, 4.2.1, ...) you don't use "--with-hdf5" to specify the location of the HDF5 libraries, you use CPPFLAGS and LDFLAGS, as in

CPPFLAGS=-I/usr/local/hdf5/include LDFLAGS=-L/usr/local/hdf5/lib ./configure
The reason for this change is explained here.

nccopy -d and -c options for compression and chunking don't work on netCDF-4 input files

Due to a bug in nccopy, the "-d n" and "-c" options only work for classic and 64-bit input files, producing netCDF-4 classic model output files. These options are also useful for netCDF-4 files to compress or recompress files and to chunk or rechunk variables. The bug description and its resolution have been entered into the issue tracker.

The bug has been fixed in all releases since 4.1.3, including the netcdf-4.2-rc1 release candidate.

Debug statement left in F90 source

The debugging statement

        print *, values(1, 1), values(1, 2), values(1, 3), values(1, 4)
was inadvertently left in the file f90/netcdf_expanded.f90 at line 734, and should be removed. If the variable has a second dimension less than 4, this can cause a segfault. The problem has been fixed in the subsequent netcdf-fortran-4.2 release.

Ncgen is known to produce bad output.

Dave Allured at NOAA has reported that the ncgen for 4.1.1 produces bad .nc files under circumstances. We recommend that this version of ncgen should not be used.

Building with Intel Fortran on Mac OS X

Setting the environment variable lt_cv_ld_force_load=no before invoking the configure script is a workaround to successfully build netCDF version 4.1.3 with the Intel ifort Fortran compiler. Specifically, the following works on Mac OS X 10.7.x (Lion) for building C and Fortran libraries and passing all tests on Lion:

$ lt_cv_ld_force_load=no FC="ifort" CC="cc" CXX="" \
  CPPFLAGS=-I/WHERE_HDF5_IS_INSTALLED/include ./configure
  make check

(The CXX environment variable is set to "" in this example to disable building and testing the legacy netCDF-3 C++ API, because of an as yet unsolved error that's not relevant to this Fortran problem.)

Accessing OPeNDAP servers using a constraint expression

The use of subsetting by specifying a URL with subsetting information to dap-enabled netCDF is broken for stable release 4.1.3. This can be demonstrated by using the 4.1.3 version of ncdump to access data from an OPeNDAP server, using a constraint expression in the URL, which results in the error message

NetCDF: Malformed or inaccessible DAP DDS

This bug is fixed in 4.2 releases after 2011-09-11, as well as by fixing the 4.1.3 release using the 3 replacement source files in this tar file.

Configuring with "--enable-benchmarks" option

Using the "--enable-benchmarks" option to the configure script fails with a compile error on some platforms, and has been reported to fail in other ways on some other platforms.

Problem with disabling fill mode when using Lustre (or other large blksize file system)

Joerg Henrichs has reported a bug when writing netCDF classic format data with fill mode disabled, on a file system such as Lustre that uses a large disk block size (for example 2 MB). On such a system, tests run by "make check" may all pass, but some write operations will fail without reporting an error.

A fix is available. in netCDF-4.1.3-beta1 or later and also in this patch for the file libsrc/posixio.c in netCDF-4.1.2 and earlier versions.

An example that failed depended on all the following circumstances:

Workarounds include avoiding use of no-fill mode (NC_NOFILL), enabling share mode (NC_SHARE), changing the order of writes of a multidimensional variable written in reverse order, or creating the file using nc__create with a blocksize outside the range in which erroneous writes occur. Some of these workarounds slow the write performance of netCDF.

"make check" fails when linked with HDF5-1.8.6

When built with HDF5 version 1.8.6, version 4.1.1 fails one of the tests invoked by "make check":

  *** Checking that one var, two dimscales, one att file can still be read by HDF5...ok.
  *** Creating a HDF5 file with one var and no dimension scales...ok.
  HDF5-DIAG: Error detected in HDF5 (1.8.6) thread 0:
    #000: H5O.c line 717 in H5Oget_info_by_idx(): group not found
      major: Symbol table
      minor: Object not found
    #001: H5Gloc.c line 591 in H5G_loc_find_by_idx(): can't find object
      major: Symbol table
      minor: Object not found
  PASS: tst_endian_fill
  1 of 59 tests failed
  Please report to
  make[2]: *** [check-TESTS] Error 1

Currently the workarounds are to either

The HDF5 1.8.5-patch1 release is available from the HDF5 site at or from the netCDF-4 ftp site at

Make tries to regenerate documentation with texi2dvi command

After building netCDF-4.1.1, invoking "make clean", and then building it again with "make all" or "make check", a failure to find the texi2dvi command is reported:

make[1]: Entering directory `/usr/local/netcdf/netcdf-4.1.1/man4'
	MAKEINFO='/bin/sh /usr/local/netcdf/netcdf-4.1.1/missing --run makeinfo   -I .' \
	texi2dvi -s  --pdf --batch netcdf.texi
make[1]: Leaving directory `/usr/local/netcdf/netcdf-4.1.1/man4'
/bin/sh: texi2dvi: command not found

This results from a bug where "make clean" erroneously deleted the documentation generated for the release, so make tries to regenerate the documentation from source, which will fail if you don't happen to have the "texi2dvi" program installed (which you shouldn't need).

This is fixed in the current snapshot and in the upcoming release 4.1.2, but a workaround is to get a new copy of the 4.1.1 source and rebuild from that with the same settings you used to get to the above message, without invoking "make clean" until after the software and documentation is successfully installed. An alternative workaround is to just invoke "make install" after the error above and use online documentation.

Accessing a multidimensional variable with more than 4 billion values on a 32-bit platform

Kari Hoijarvi has reported a bug in implementation of large variable support that has been in netCDF software since at least 1997, and which is fixed in netCDF snapshots after 2010-05-13 as well as in the upcoming netCDF-4.1.2 release. The bug occurs when all of the following conditions are met:

In this case an undetected integer overflow occurred in calculating the file offset, and the values were written to or read from the wrong location in the file, overwriting data stored at that location in the case of a write.

The fix is a one-line change to a line in the libsrc/putget.m4 file, from which the libsrc/putget.c file is generated, replacing the statement

		    lcoord += *up * *ip;
		    lcoord += (off_t)(*up) * (off_t)(*ip);

Known Problems with netCDF 4.0.1

Including mpi.h before netcdf.h breaks MPI

Luis Kornblueh reports a subtle bug in netcdf 4.0.1. In the netcdf.h header file, the following mpi entities are defined:

 /* These defs added by netCDF configure because parallel HDF5 is not 
 present. */
 #define MPI_Comm int
 #define MPI_Info int
 #define MPI_COMM_WORLD 0
 #define MPI_INFO_NULL 0

If mpi.h is included before netcdf.h, these defines (may) break the MPI implementation.

With Sun C compiler, 64-bit ncdump fails

As identified by Udo Grabowski, using the "-m64" option to build netCDF with the Sun C compiler results in a failed test when running "make check" in the ncdump directory:

*** checking that test1.cdl and are the same...
<   8.88178419700125e-16, 1.11022302462516e-15, 1.33226762955019e-15,
<   1.55431223447522e-15, 1.77635683940025e-15, 222044604925031 ;
>   1.97215226305253e-31, 2.46519032881567e-31, 2.9582283945788e-31,
>   3.45126646034193e-31, 3.94430452610506e-31, 0.0493038065763132 ;

This bug is fixed in recent Sun C compiler releases, for example "Sun C 5.11 SunOS_i386 Aten 2010/05/10".

Short of upgrading the compiler, other workarounds include specifying

CFLAGS="-O0 -m64" 
before rerunning the configure script, to turn off optimization, or just install an ncdump built without "-m64". Because ncdump reads only a little data at a time, there is no benefit to a 64-bit ncdump. The 32-bit ncdump handles classic, 64-bit offset, and netCDF-4 files correctly even if they are larger than 4 GiB.

Portland Group compilers can't build shared fortran 90 library or shared C++ library

The portland group compilers can't build netCDF shared fortran 90 library. They fail with this error:

pgf90  -I../fortran -I../f90      -I../libsrc -I../fortran   -I../f90
-g -c -o tst_f90.o tst_f90.f90
/bin/sh ../libtool   --mode=link pgf90  -I../fortran -I../f90 --
		     ---I../libsrc -I../fortran   -I../f90 -g -L/lib --
		     ---o tst_f90 tst_f90.o ../fortran/ --
		     ---lm     ../libsrc/  
libtool: link: pgf90 -I../fortran -I../f90 -I../libsrc -I../fortran
-I../f90 -g -o .libs/tst_f90 tst_f90.o  -L/lib
../fortran/.libs/ -lm ../libsrc/.libs/
tst_f90.o:(.debug_info+0x135d): undefined reference to
tst_f90.o:(.debug_info+0x136e): undefined reference to `..Dm_netcdf'

If anyone could shed some light on this, it would be most appreciated. Send comments to

The C++ compiler chokes on the netCDF C++ tests on a shared build:

       pgCC -DHAVE_CONFIG_H -I. -I.. -I../fortran -I../libdap
       -I../libsrc   -g -c -o tst_failure.o tst_failure.cpp
/bin/sh ../libtool --tag=CXX   --mode=link pgCC  -g     -o tst_failure
       tst_failure.o ../cxx/  ../libsrc/
libtool: link: pgCC -g -o .libs/tst_failure tst_failure.o
       ../cxx/.libs/ ../libsrc/.libs/
       -Wl,--rpath -Wl,/usr/local/lib
make[2]: Leaving directory `/machine/shecky/n4_new2/cxx'
make  check-TESTS
make[2]: Entering directory `/machine/shecky/n4_new2/cxx'
C++ runtime abort: internal error: static object marked for
       destruction more than once
/bin/sh: line 4:  8445 Aborted                 ${dir}$tst
FAIL: nctst
C++ runtime abort: internal error: static object marked for
       destruction more than once
/bin/sh: line 4:  8468 Aborted                 ${dir}$tst
XFAIL: tst_failure

There is a problem with the pgCC compiler noted as "Fixed in version 6.2.1" described as

  C++ runtime abort: internal error: static object marked for
  destruction more than once

here as Technical Problem Report 3809.

This bug was also previously reported by a user.

Intel 10.1 64-bit C++ compiler problem

On my test machine, the intel 10.1 C++ compiler cannot build the netCDF C++ API in 64-bit mode. I get an error like this:

make[1]: Entering directory
depbase=`echo netcdf.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../libtool --tag=CXX   --mode=compile icpc -DHAVE_CONFIG_H
-I. -I.. -I../fortran -I../libdap      -I../libsrc
-I/opt/intel/cce/10.1.015/include -MT netcdf.lo -MD -MP -MF
$depbase.Tpo -c -o netcdf.lo netcdf.cpp &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  icpc -DHAVE_CONFIG_H -I. -I.. -I../fortran
-I../libdap -I../libsrc -I/opt/intel/cce/10.1.015/include -MT
netcdf.lo -MD -MP -MF .deps/netcdf.Tpo -c netcdf.cpp -o netcdf.o
error: argument of type "__va_list_tag *" is incompatible with
parameter of type "char *"
      const int __ret = __builtin_vsnprintf(__out, __size, __fmt,

compilation aborted for netcdf.cpp (code 2)
make[1]: *** [netcdf.lo] Error 1
make[1]: Leaving directory
make: *** [check-recursive] Error 1

This is because the Intel C++ compiler has not caught up to the GNU C++ compiler, and for some reason that is not clear to me, it is using the header files from gcc.

To solve this problem, install an older version of gcc (4.1.2 works in testing at Unidata World Test Center, located at the bottom of a six-mile deep mine shaft.) Put the bin directory at the beginning of your PATH, and the lib (or lib64) directory at the beginning at the LD_LIBRARY_PATH. Then rebuild.

Intel 9.1 C++ compiler problem doesn't build C++ API

On my test machine, the intel 9.1 C++ compile fails like this:

make  nctst tst_failure
make[2]: Entering directory
depbase=`echo nctst.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
icpc -DHAVE_CONFIG_H -I. -I.. -I../fortran -I../libdap
-I../libsrc   -I/opt/intel/cc/9.1.047/include/c++/ -MT nctst.o -MD -MP
-MF $depbase.Tpo -c -o nctst.o nctst.cpp &&\
mv -f $depbase.Tpo $depbase.Po
/bin/sh ../libtool --tag=CXX   --mode=link icpc
-I/opt/intel/cc/9.1.047/include/c++/     -o nctst nctst.o
../cxx/  ../libsrc/  
libtool: link: icpc -I/opt/intel/cc/9.1.047/include/c++/ -o nctst
nctst.o  ../cxx/.libs/libnetcdf_c++.a ../libsrc/.libs/libnetcdf.a
nctst.o: In function `main':
nctst.cpp:(.text+0x22e): undefined reference to
`std::ios_base::clear(std::_Iosb::_Iostate, bool)'
nctst.cpp:(.text+0x290): undefined reference to
`std::ios_base::clear(std::_Iosb::_Iostate, bool)'
nctst.cpp:(.text+0x3b1): undefined reference to
`std::ios_base::clear(std::_Iosb::_Iostate, bool)'
nctst.cpp:(.text+0x520): undefined reference to
`std::ios_base::clear(std::_Iosb::_Iostate, bool)'
nctst.cpp:(.text+0x582): undefined reference to
`std::ios_base::clear(std::_Iosb::_Iostate, bool)'
nctst.o:nctst.cpp:(.text+0x767): more undefined references to
`std::ios_base::clear(std::_Iosb::_Iostate, bool)' follow
nctst.o: In function `__sti__$E':
nctst.cpp:(.text+0x2cb0): undefined reference to
nctst.cpp:(.text+0x2cbf): undefined reference to `std::_Winit::~_Winit()'

Anyone who can shed light on this should send email to

ncgen/ncdump test failure with Intel version 11 compilers

Ed Anderson reports that the tests of the netcdf-4.0 (and presumable 4.0.1 and 3.6.3) package fail with the recently released version 11 of the Intel compilers, producing the error message:

*** creating UTF-8 test file! Unexpected result, tst_utf8.c, line: 63
Sorry! Unexpected result, tst_utf8.c, line: 68
Sorry! Unexpected result, tst_utf8.c, line: 72
Sorry! Unexpected result, tst_utf8.c, line: 79
Sorry! Unexpected result, tst_utf8.c, line: 90
Sorry! Unexpected result, tst_utf8.c, line: 92
Sorry! Unexpected result, tst_utf8.c, line: 114
Sorry! Unexpected result, tst_utf8.c, line: 117
Sorry! Unexpected result, tst_utf8.c, line: 119
Sorry! Unexpected result, tst_utf8.c, line: 122
/bin/sh: line 1:  5216 Segmentation fault      ${dir}$tst
FAIL: tst_utf8

*** Testing ncgen and ncdump for UTF8 support...
*** creating classic offset file with utf8 characters...
ncgen: NetCDF: Name contains illegal characters
ncgen: NetCDF: Invalid dimension ID or name
ncgen: NetCDF: Name contains illegal characters
2 of 8 tests failed

Ed also reports this is a compiler problem (which has been reported) and that there is a workaround:

... in libsrc/string.c the test

if(ch <= 0x7f) {

can be changed (in two places) to

if(ch < 0x7f || ch == 0x7f) {

This was the only change I needed to pass the netcdf-4 tests with Intel
version 11.

"ncdump -v group/var" reports "group not found"

John Storrs reported a bug using ncdump -v applied to netCDF-4 files, in which an erroneous 'group not found' message was displayed for valid group/var names. This is fixed in the next release, and the fix is also in the current snapshot release.

Known Problems with netCDF 4.0

Ncdump assumes default fill value for unsigned byte data

The ncdump utility incorrectly assumes a default fill value of "255" for data of unsigned byte type, although no default fill value is assumed for data of type signed byte. There should be no default fill values when reading any byte type, signed or unsigned, because the byte ranges are too small to assume one of the values should appear as a missing value unless a _FillValue attribute is set explicitly. This bug is fixed in the current snapshot distribution.

Ncdump of compound type with array field

Running the ncdump utility on a file with a compound type with an array field may result in a segmentation violation. A fix is in the current netCDF-4.0 snapshot distribution.

Memory leak with VLEN attributes

We believe there are some memory leaks associated with VLEN attributes in HDF5 1.8.1. This is being addressed by the HDF5 team, and will be fixed by the next HDF5 release.

Error dyld: Symbol not found: _H5P_CLS_FILE_ACCESS_g

On some Macintosh systems here at NetCDF World Test Center, on the hundreth floor of UCAR Tower #2, the following build error occurs:

*** Checking HDF5 enum types.
*** Checking simple HDF5 enum type...ok.
*** Checking HDF5 enum type missing values...ok.
*** Tests successful!
PASS: tst_h_enums
dyld: Symbol not found: _H5P_CLS_FILE_ACCESS_g
  Referenced from:
  Expected in: flat namespace

FAIL: tst_lists
dyld: Symbol not found: _H5P_CLS_FILE_ACCESS_g
  Referenced from:
  Expected in: flat namespace

FAIL: tst_dims
dyld: Symbol not found: _H5P_CLS_FILE_ACCESS_g
  Referenced from:
  Expected in: flat namespace


This can be caused by the configure script failing to add "-lhdf5" to the link flags in the generated Makefiles. Set LDFLAGS to include "-L/WHERE/HDF5/IS/INSTALLED/lib -lhdf5" and try again.

Bug with multiple unlimited dimensions in one var

There is a bug in the 4.0 release related to the lengths of dimensions when more than one unlimited dimension is used in the same variable.

The bug is fixed in the latest netCDF-4 snapshot release.

Fortran90 interface Using Intel ifort under Cygwin

Chris Dallimore reports success in getting the Fortran 90 interface of Version 4.0 to compile under CYGWIN using the Intel ifort compile;

1 - Download and unpack netcdf-4.0.tar.gz

2 - In configure replace conftest.o and conftestf.o with conftest. 
$ac_objext and conftest.$ac_objext, I'm Not sure why autoconf doesn't  
do this.

3 -
Save as libsrc/ 
Save ttp:// as libsrc/ 

modify line 43 of libsrc/inttypes_msvc.h

4 - in libsrc utf8proc.h at line 79 replaces



#ifndef _MSC_VER
typedef long ssize_t;
typedef unsigned int uint32_t;

It looks like configure is checking for ssize_t so there is probably a  
better way to do this.

5 -
in libsrc/posixio.c at line 18 replace

#ifdef _MSC_VER /* Microsoft Compilers */


#ifdef _MSC_VER /* Microsoft Compilers */
typedef long ssize_t;
typedef unsigned int uint32_t;

6 -
in putget.m4 at line 24 added

#ifdef _MSC_VER
#endif // _MSC_VER ]

./configure --prefix=/cygdrive/z/cwr/Software/Eclipse/CWRModelSource -- 
disable-examples  --disable-cxx --disable-utilities

Relevant environment variables
FFLAGS=/debug:full /traceback  /nologo
FCFLAGS=/debug:full /traceback  /nologo
FCFLAGS_f90=/debug:full /traceback  /nologo
CPPFLAGS=/D AbsoftProFortran /D _MSC_VER /nologo

IFORT_COMPILER10_POSIX=/cygdrive/c/Program Files/Intel/Compiler/ 
VSINSTALLDIR=C:\Program Files\Microsoft Visual Studio 8
INTEL_LICENSE_FILE=C:\Program Files\Common Files\Intel\Licenses
PROCESSOR_IDENTIFIER=x86 Family 6 Model 15 Stepping 6, GenuineIntel
MAKEFLAGS=w -- F90=ifort
VS80COMNTOOLS=C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\
VSINSTALLDIR_POSIX=/cygdrive/c/Program Files/Microsoft Visual Studio 8
F90FLAGS=/debug:full /traceback  /nologo
VCINSTALLDIR=C:\Program Files\Microsoft Visual Studio 8\VC
INTEL_SHARED=C:\Program Files\Common Files\Intel\Shared Files
LIB=C:\Program Files\Intel\Compiler\Fortran\10.1.013\Ia32\Lib;C: 
\Program Files\Microsoft Visual Studio 8\VC\atlmfc\lib;C:\Program Files 
\Microsoft Visual Studio 8\VC\lib;C:\Program Files\Microsoft Visual  
Studio 8\VC\PlatformSDK\lib;C:\Program Files\Microsoft Visual Studio 
\DF98\LIB;C:\Program Files\Microsoft Visual Studio\VC98\LIB
IFORT_COMPILER10=C:\Program Files\Intel\Compiler\Fortran\10.1.013
VCINSTALLDIR_POSIX=/cygdrive/c/Program Files/Microsoft Visual Studio 8/ 
PATH=/cygdrive/c/Program Files/Intel/Compiler/Fortran/10.1.013/Ia32/ 
Bin:/cygdrive/c/Program Files/Common Files/Intel/Shared Files/Ia32/ 
Bin:/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/IDE:/ 
cygdrive/c/Program Files/Microsoft Visual Studio 8/VC/bin:/cygdrive/c/ 
Program Files/Microsoft Visual Studio 8/Common7/Tools:/cygdrive/c/ 
Program Files/Microsoft Visual Studio 8/Common7/Tools/bin:/cygdrive/c/ 
Program Files/Microsoft Visual Studio 8/VC/PlatformSDK/bin:/cygdrive/c/ 
cygdrive/c/Program Files/Microsoft Visual Studio/Common/Tools:/ 
cygdrive/c/Program Files/Microsoft Visual Studio/Common/Msdev98/BIN:/ 
cygdrive/c/Program Files/Microsoft Visual Studio/DF98/BIN:/cygdrive/c/ 
Program Files/Microsoft Visual Studio/VC98/BIN:/cygdrive/c/Sun/SDK/jdk/ 
Wbem:/cygdrive/c/Program Files/jEdit:/cygdrive/c/Program Files/ 
Microsoft SQL Server/90/Tools/binn/:/cygdrive/c/Program Files/Intel/ 
Compiler/Fortran/10.1.013/IA32/Lib:/cygdrive/c/Program Files/Intel/ 
Compiler/Fortran/10.1.013/EM64T/Lib:/cygdrive/c/Program Files/MATLAB/ 
R2008a/bin:/cygdrive/c/Program Files/MATLAB/R2008a/bin/win32
INTEL_SHARED_POSIX=/cygdrive/c/Program Files/Common Files/Intel/Shared  
INCLUDE=C:\Program Files\Intel\Compiler\Fortran 
\10.1.013\Ia32\Include;C:\Program Files\Microsoft Visual Studio 8\VC 
\atlmfc\include;C:\Program Files\Microsoft Visual Studio 8\VC 
\include;C:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK 
\include;C:\Program Files\Microsoft Visual Studio\DF98\INCLUDE;C: 
\Program Files\Microsoft Visual Studio\VC98\INCLUDE

Now configure works

make will compile but fails on linking

libtool: link: ( cd ".libs" && rm -f "" && ln -s "../" "" )
/bin/sh ../libtool --tag=CC   --mode=link /cygdrive/z/cwr/Software/ 
cl      -version-info 4:0:0   -o -rpath /cygdrive/z/cwr/ 
Software/Eclipse/CWRModelSource/lib attr.lo ncx.lo putget.lo dim.lo  
error.lo libvers.lo nc.lo string.lo v1hpg.lo var.lo utf8proc.lo   
posixio.lo ../fortran/
libtool: link: warning: undefined symbols not allowed in i686-pc- 
cygwin shared libraries
libtool: link: (cd .libs/libnetcdf.lax/libnetcdf2.lib && ar x "/ 
libtool: link: (cd .libs/libnetcdf.lax/libnetcdff.lib && ar x "/ 
.libs/libnetcdff.lax/libnetcdff90.lib/typeSizes.obj: No such file or  

It looks like the Microsoft LInker doesn't like the GNU lib format.

I was however able to compile and link using some static (ie non  
automake) makefiles that are part of our overall model build  

ncdump bug for filenames beginning with a numeric character

The ncdump utility in releases 4.0 and 3.6.3 rejects filenames starting with the digits 0,1 and 2 with an error message such as:

  ncdump: name begins with space or control-character: 2

This bug is fixed in the daily snapshot release and in 4.0.1-beta releases, but a one-line patch to ncdump/dumplib.c (for either netCDF-4.0 or netCDF-3.6.3) is to replace the line

 if((*cp >= 0x01 && *cp <= 0x32) || (*cp == 0x7f))

with the following line instead

 if((*cp >= 0x00 && *cp <= 0x20) || (*cp == 0x7f))

Known Problems with netCDF 3.6.3

Can't build shared library with F90 API on IRIX

When building shared libraries on out IRIX test system, I got the following error:

ld32: FATAL   12 : Expecting n32 objects: /lib/ is o32.

Obviously there is some ABI confusion here, but we don't know how to resolve it. Any user who can solve this should email so that we can share the method with other users.

Known Problems with netCDF 3.6.2

Setting ARFLAGS does not work

Sometimes when building netCDF, flags to the ar utility need to be set. Setting ARFLAGS does not work.

(Note: If you are doing this to build 64-bit libraries on an AIX platform, the most fool-proof way to built 64-bit applications under AIX is to set the OBJECT_MODE environment variable to 64. If you still feel you must setr flags for ar, read on.)

Try the build again, setting AR_FLAGS instead of ARFLAGS.

Bugs in support for variables larger than 4 GiB

As first reported by Mario Emmenlauer, there is a bug in netCDF-3.6.2 (and earlier versions) in the code for creating byte and short type variables greater than 4 GiB in size. This problem resulted in an assertion violation or arithmetic exception that would have caused a program to halt, rather than writing bad data or corrupting existing data.

A fix is available as a patch to the file libsrc/var.c in the netcdf-3.6.2 distribution. The bug is also fixed in releases 3.6.3 and later.

  1. On 32-bit platforms (with size_t an unsigned 32-bit type):
  2. On 64-bit platforms (with size_t an unsigned 64-bit type):

Bug in C++ interface prevents creating 64-bit offset format files

As reported by Jos Verdoold, a bug in the netCDF 3.6.2 (and earlier versions) C++ interface prevents creating new files in Offset64Bits mode using the C++ API. The fix is to change two lines (378 and 393) in the file src/cxx/netcdf.cpp, changing "=" to "|=" in each line, then rebuild:

< 	mode = NC_WRITE;
> 	mode |= NC_WRITE;
< 	mode = NC_NOCLOBBER;
> 	mode |= NC_NOCLOBBER;

This fix has been incorporated into netCDF 3.6.3 and later versions.

The tests in nf_test fail with seg fault with the Absoft Version 10.0 fortran compiler.

The absoft fortran compiler, version 10.0, changes the way that a C function returning string is called from fortran.

This causes the absoft fortran settings in cfortran.h to no longer work, and this is reflected in a segmentation fault in the test program nf_test/nf_test.

As a workaround, users with absoft version 10 can get the latest netCDF-3 snapshot and build it with the --enable-absoft10-hack option set.

Get the snapshot, and see the working output, on the netCDF-3 snapshot page.

Shared libraries do not work with the NAG fortran compiler.

We have reports that the shared library build does not work with the NAG fortran compiler. The NAG compiler is not one of the compilers we current support (and test on) at Unidata. The only known work around is to build without the --enable-shared option.

Any user who can debug this problem with the NAG compiler should send the resuts to, so that it can be incorporated into the netCDF distribution.

Interested users may also wish to subscribe to the netcdf-porting mailing list.

The documented --enable-64bit option doesn't work.

The --enable-64bit option appeared in the 3.6.1 release, and was-- removed for the 3.6.2 release.

Unfortunately, the documentation was not updated, so that the 3.6.2 documentation still mentions the enable-64bit option. Sorry about that.

The documentation has been corrected for the netCDF-3 snapshot and the netCDF-4 snapshot documentation.

Building netCDF-3.6.2 with gfortran version 4.2.x or 4.3.x fails.

Something changed in gfortran version 4.3 relating to how fortran functions can call C functions.

In netCDF, the interface between C and Fortran is handled by the cfortran.h package, which requires a pre-processor define describing the type of fortran you are using.

For gfortran up to version 4.1.x, the netCDF distribution builds cleanly with the "gFortran" preprocessor symbol set. For gfortran 4.2.x and greater, the "pgiFortran" preprocessor symbol works.

The 3.6.2 build uses "gFortran", unless you specifically set the CPPFLAGS environmental variable to "-DpgiFortran".

This works in my bash shell:

FC=gfortran CPPFLAGS=-DpgiFortran ./configure && make check

This problem has been fixed in the netCDF-3 snapshot. Now configure checks the version of gfortran before setting the appropriate flag.

Building shared libraries on Macintosh with g95 fails.

Building shared libraries on the Macintosh fails

*** Testing netCDF-3 Fortran 90 API.
dyld: lazy symbol binding failed: Symbol not found: __g95_size
  Referenced from:
  Expected in: flat namespace

dyld: Symbol not found: __g95_size
  Referenced from:
  Expected in: flat namespace

FAIL: tst_f90
1 of 5 tests failed
Please report to

Building shared libraries on HPUX with native tools results in only static libraries.

On the only HPUX machine I have access to for testing, the --enable-shared still results in only the static library being linked.

This may be because of and old C++ compiler on this particular platform. Any HPUX use who can provide information about this should send email to bash-2.04$ uname -a HP-UX tweety B.11.00 A 9000/785 2004553471

Building shared libraries on AIX fails.

On the Unidata AIX platforms, the shared netCDF build fails with either the Fortran or C++ compilers, like this:

make  check-TESTS
*** Creating
/bin/sh: 16012 Segmentation fault(coredump)
FAIL: nf_test
/bin/sh: 16018 Segmentation fault(coredump)
FAIL: tst_f77_v2
/bin/sh: 16024 Segmentation fault(coredump)
FAIL: ftest
3 of 4 tests failed
Please report to

If built without fortran or C++, the build succeeds, but shared libraries are not built. (Static libraries are).

I don't know what is causing this. If any AIX users can shed any light, that would be most helpful.

Shared builds also fail the same way when using GNU compilers.

Building with older versions of g++ fails.

The build fails like this:

libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../fortran -DDEBUG -I../libsrc -g -O2 -MT netcdf.lo -MD -MP -MF .deps/netcdf.Tpo -c netcdf.cpp -o netcdf.o
In file included from /opt/gnu/gcc/include/c++/3.2/powerpc-ibm-aix5.0.0.0/bits/c++io.h:35,
                 from /opt/gnu/gcc/include/c++/3.2/bits/fpos.h:44,
                 from /opt/gnu/gcc/include/c++/3.2/iosfwd:46,
                 from /opt/gnu/gcc/include/c++/3.2/ios:44,
                 from /opt/gnu/gcc/include/c++/3.2/ostream:45,
                 from /opt/gnu/gcc/include/c++/3.2/iostream:45,
                 from netcdf.cpp:13:
/opt/gnu/gcc/include/c++/3.2/cstdio:108: `fgetpos' not declared
/opt/gnu/gcc/include/c++/3.2/cstdio:110: `fopen' not declared
/opt/gnu/gcc/include/c++/3.2/cstdio:115: `freopen' not declared
/opt/gnu/gcc/include/c++/3.2/cstdio:118: `fsetpos' not declared
netcdf.cpp: In member function `NcBool NcVar::set_cur(long int, long int, long 
   int, long int, long int)':

This happens in old versions of g++ when large files are used. To fix this, either upgrade your g++ compiler, or else use --disable-largefile with configure, to turn off large file handling.

The .NET build files are not included in the 3.6.2 release.

The netCDF 3.6.2 release does not contain the .NET build files. Whoops! Sorry about that.

.NET users should use the latest snapshot, or continue to use the 3.6.1 release.

This is now fixed in the netCDF-3 snapshot. Get the snapshot from the netCDF-3 snapshot build page.

Snapshot .NET build files do not work for Visual Studio 8.0 beta.

A user has reported that Visual Studio .NET version 8.0 beta does not build with the netCDF .NET build files in win32/NET.

Interested users may also wish to subscribe to the netcdf-porting mailing list.

The -disable-v2 option causes the fortran build to fail with some fortran compilers.

The netCDF version 2 API is maintained for backward compatibility. We are committed to maintaining the V2 API for all future releases of netCDF. However, the --disable-v2 option is provided -- for users who wish to compile the netCDF libraries without the V2 API.

The --disable-v2 option will cause the fortran build to fail on some fortran 95 compilers because the file still includes the names of the V2 API functions. (Other fortran 90 compilers ignore these).

If your compiler fails with --disable-v2, you can either refrain from using this option (that is, build the v2 API as well as the V3 API), or you can get the netCDF-3 snapshot.

This is fixed for future releases of netCDF.

The --disable-c option does not work.

The --disable-c option should turn off the building of the netCDF C library for use with --enable-separate-fortran (to save a small amount of tme building and testing. However this does not happen. The C library is built in any case.

Users may ignore this option in version 3.6.2. It is fixed in the netCDF-3 snapshot and for future releases of netCDF.

Known Problems with netCDF 3.6.1