1 # Known Problems with netCDF {#known_problems}
4 Known Problems with netCDF 4.3.0
5 --------------------------------
7 - [clang compiler (default on OSX 10.9 Mavericks) detects error
8 building ncgen3](#clang-ncgen3)
10 Known Problems with netCDF 4.2
11 ------------------------------
13 - [Fortran options of nc-config utility (--fflags, --flibs, --has-f90)
14 don't work correctly](#nc-config-fortran)
15 - [Using "--with-hdf5=..." configure option doesn't seem to
18 Known Problems with netCDF 4.1.3
19 --------------------------------
21 - [nccopy -d and -c options for compression and chunking don't work on
22 netCDF-4 input files](#nccopy-compression-bug)
23 - [Debug statement left in F90 source](#f90-debug-segfault)
24 - [Building with Intel Fortran on Mac OS X](#intel-fortran-macosx)
25 - [Accessing OPeNDAP servers using a constraint expression](#dap-413)
26 - [Configuring with "--enable-benchmarks"
27 option](#enabling-benchmarks)
29 Known Problems with netCDF 4.1.2
30 --------------------------------
32 - [Building with Intel Fortran on Mac OS X](#intel-fortran-macosx)
33 - [Problem with disabling fill mode when using Lustre (or other large
34 blksize file system)](#lustre)
36 Known Problems with netCDF 4.1.1
37 --------------------------------
39 - [Ncgen is known to produce bad output and should not
41 - [Building with Intel Fortran on Mac OS X](#intel-fortran-macosx)
42 - ["make check" fails when linked with HDF5-1.8.6](#incompat-411-186)
43 - [Make tries to regenerate documentation with texi2dvi
45 - [Accessing a multidimensional variable with more than 4 billion
46 values on a 32-bit platform](#big-mvar-32bit)
48 ------------------------------------------------------------------------
50 ### The clang compiler (default on OSX 10.9 Mavericks) detects error building ncgen3
52 Building the netCDF C library with the clang C compiler, the default
53 /usr/bin/cc on OSX 10.9 Mavericks, detects an error in compiling
54 ncgen3/load.c. A fix is to insert the line
58 above the "`#include <stdlib.h>`" statement near the beginning of
61 This fix will be in the next release.
63 ### Fortran options of nc-config utility (--fflags, --flibs, --has-f90) don't work correctly
65 Beginning with version 4.2 of the C-based netCDF software, the netCDF
66 Fortran library is built from an independent netcdf-fortran release with
67 its own nf-config utility. In netCDF-4.2 the nc-config utility doesn't
68 detect whether nf-config is installed and make use of its output to
69 preserve backward compatibility with nc-config from previous releases.
70 This problem is fixed in netCDF-4.2.1-rc1 and later releases.
72 ### Using "--with-hdf5=..." configure option doesn't seem to work
74 With releases of netCDF-4 after version 4.1.2 (this includes 4.1.3, 4.2,
75 4.2.1, ...) you don't use "--with-hdf5" to specify the location of the
76 HDF5 libraries, you use CPPFLAGS and LDFLAGS, as in
78 CPPFLAGS=-I/usr/local/hdf5/include LDFLAGS=-L/usr/local/hdf5/lib ./configure
80 The reason for this change is explained
81 [here](https://www.unidata.ucar.edu/jira/browse/NCF-20).
83 ### nccopy -d and -c options for compression and chunking don't work on netCDF-4 input files
85 Due to a bug in nccopy, the "-d n" and "-c" options only work for
86 classic and 64-bit input files, producing netCDF-4 classic model output
87 files. These options are also useful for netCDF-4 files to compress or
88 recompress files and to chunk or rechunk variables. The bug description
89 and its resolution have been
90 [entered](https://www.unidata.ucar.edu/jira/browse/NCF-79) into the
93 The bug has been fixed in all releases since 4.1.3, including the
94 netcdf-4.2-rc1 release candidate.
96 ### Debug statement left in F90 source
98 The debugging statement
100 print *, values(1, 1), values(1, 2), values(1, 3), values(1, 4)
102 was inadvertently left in the file f90/netcdf\_expanded.f90 at line 734,
103 and should be removed. If the variable has a second dimension less than
104 4, this can cause a segfault. The problem has been fixed in the
105 subsequent netcdf-fortran-4.2 release.
107 ### Ncgen is known to produce bad output.
109 Dave Allured at NOAA has reported that the ncgen for 4.1.1 produces bad
110 .nc files under circumstances. We recommend that this version of ncgen
113 ### Building with Intel Fortran on Mac OS X
115 Setting the environment variable **lt\_cv\_ld\_force\_load=no** before
116 invoking the configure script is a workaround to successfully build
117 netCDF version 4.1.3 with the Intel ifort Fortran compiler.
118 Specifically, the following works on Mac OS X 10.7.x (Lion) for building
119 C and Fortran libraries and passing all tests on Lion:
121 $ lt_cv_ld_force_load=no FC="ifort" CC="cc" CXX="" \
122 LDFLAGS=-L/WHERE_HDF5_IS_INSTALLED/lib \
123 CPPFLAGS=-I/WHERE_HDF5_IS_INSTALLED/include ./configure
126 (The CXX environment variable is set to "" in this example to disable
127 building and testing the legacy netCDF-3 C++ API, because of an as yet
128 unsolved error that's not relevant to this Fortran problem.)
130 ### Accessing OPeNDAP servers using a constraint expression
132 The use of subsetting by specifying a URL with subsetting information to
133 dap-enabled netCDF is broken for stable release 4.1.3. This can be
134 demonstrated by using the 4.1.3 version of ncdump to access data from an
135 OPeNDAP server, using a constraint expression in the URL, which results
138 NetCDF: Malformed or inaccessible DAP DDS
140 This bug is fixed in 4.2 releases after 2011-09-11, as well as by fixing
141 the 4.1.3 release using the 3 replacement source files in [this tar
142 file](http://www.unidata.ucar.edu/downloads/netcdf/ftp/4.1.3-fix.tar).
144 ### Configuring with "--enable-benchmarks" option
146 Using the "--enable-benchmarks" option to the configure script fails
147 with a compile error on some platforms, and has been reported to fail in
148 other ways on some other platforms.
150 ### Problem with disabling fill mode when using Lustre (or other large blksize file system)
152 Joerg Henrichs has reported a bug when writing netCDF classic format
153 data with fill mode disabled, on a file system such as Lustre that uses
154 a large disk block size (for example 2 MB). On such a system, tests run
155 by "make check" may all pass, but some write operations will fail
156 without reporting an error.
158 A fix is available. in netCDF-4.1.3-beta1 or later and also in [this
159 patch](/software/netcdf/patches/nofill-bug.patch) for the file
160 libsrc/posixio.c in netCDF-4.1.2 and earlier versions.
162 An example that failed depended on all the following circumstances:
164 - The disk block size must be within a range of sizes, in this case
165 one of the 58080 values between 2091953 and 2150032 inclusive.
166 Equivalently, the file must be created using the "double underbar"
167 function nc\_\_create() with a I/O block size in this range.
168 - No-fill mode must be set, for example by calling nc\_set\_fill()
169 with NC\_NOFILL, or by using a software package such as NCO that
170 uses no-fill mode by default.
171 - A data variable at the end of a file being created must be written
172 in reverse order from how it is stored on disk, for example writing
173 a multidimensional variable by slices in reverse order along one of
174 its more slowly varying dimensions. This must result in writing at
175 least two disk blocks beyond the end of the file.
177 Workarounds include avoiding use of no-fill mode (NC\_NOFILL), enabling
178 share mode (NC\_SHARE), changing the order of writes of a
179 multidimensional variable written in reverse order, or creating the file
180 using nc\_\_create with a blocksize outside the range in which erroneous
181 writes occur. Some of these workarounds slow the write performance of
184 ### "make check" fails when linked with HDF5-1.8.6
186 When built with HDF5 version 1.8.6, version 4.1.1 fails one of the tests
187 invoked by "make check":
190 *** Checking that one var, two dimscales, one att file can still be read by HDF5...ok.
191 *** Creating a HDF5 file with one var and no dimension scales...ok.
192 HDF5-DIAG: Error detected in HDF5 (1.8.6) thread 0:
193 #000: H5O.c line 717 in H5Oget_info_by_idx(): group not found
195 minor: Object not found
196 #001: H5Gloc.c line 591 in H5G_loc_find_by_idx(): can't find object
198 minor: Object not found
200 PASS: tst_endian_fill
201 ================================================
203 Please report to support-netcdf@unidata.ucar.edu
204 ================================================
205 make[2]: *** [check-TESTS] Error 1
207 Currently the workarounds are to either
209 - Use the earlier HDF5 1.8.5-patch1 release for building netCDF 4.1.1
210 - Use netCDF-4.1.2-beta2 or later with HDF5 1.8.6
212 The HDF5 1.8.5-patch1 release is available from the HDF5 site at
213 <http://www.hdfgroup.org/ftp/HDF5/prev-releases/> or from the netCDF-4
214 ftp site at <ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-4>.
216 ### Make tries to regenerate documentation with texi2dvi command
218 After building netCDF-4.1.1, invoking "make clean", and then building it
219 again with "make all" or "make check", a failure to find the texi2dvi
222 make[1]: Entering directory `/usr/local/netcdf/netcdf-4.1.1/man4'
223 TEXINPUTS=".:$TEXINPUTS" \
224 MAKEINFO='/bin/sh /usr/local/netcdf/netcdf-4.1.1/missing --run makeinfo -I .' \
225 texi2dvi -s --pdf --batch netcdf.texi
226 make[1]: Leaving directory `/usr/local/netcdf/netcdf-4.1.1/man4'
227 /bin/sh: texi2dvi: command not found
229 This results from a bug where "make clean" erroneously deleted the
230 documentation generated for the release, so make tries to regenerate the
231 documentation from source, which will fail if you don't happen to have
232 the "texi2dvi" program installed (which you shouldn't need).
234 This is fixed in the current snapshot and in the upcoming release 4.1.2,
235 but a workaround is to get a new copy of the 4.1.1 source and rebuild
236 from that with the same settings you used to get to the above message,
237 without invoking "make clean" until after the software and documentation
238 is successfully installed. An alternative workaround is to just invoke
239 "make install" after the error above and use online documentation.
241 ### Accessing a multidimensional variable with more than 4 billion values on a 32-bit platform
243 Kari Hoijarvi has reported a bug in implementation of large variable
244 support that has been in netCDF software since at least 1997, and which
245 is fixed in netCDF snapshots after 2010-05-13 as well as in the upcoming
246 netCDF-4.1.2 release. The bug occurs when all of the following
249 - A 32-bit version of the netCDF library is used.
250 - The file format is either classic or 64-bit offset format.
251 - Values are written to or read from a fixed-size variable that has
252 more than 2^32^ (4,294,967,296) values, or a record variable with
253 more than 2^32^ values per record. The variable must be the last
254 fixed-size variable in a file with no record variables or the last
255 record variable, because otherwise it would violate the format
256 constraints for netCDF classic or 64-bit offset formats described
257 [here](http://www.unidata.ucar.edu/netcdf/docs/netcdf/NetCDF-Classic-Format-Limitations.html).
258 Note that the bug involves number of values, not bytes, so if the
259 variable is of type integer or float, for example, it would require
261 - The variable must have 2 or more dimensions.
262 - The values to be written or read must begin after the first 2^32^
263 values of the variable.
265 In this case an undetected integer overflow occurred in calculating the
266 file offset, and the values were written to or read from the wrong
267 location in the file, overwriting data stored at that location in the
270 The fix is a one-line change to a line in the libsrc/putget.m4 file,
271 from which the libsrc/putget.c file is generated, replacing the
278 lcoord += (off_t)(*up) * (off_t)(*ip);
280 Known Problems with netCDF 4.0.1
281 --------------------------------
283 - [Including mpi.h before netcdf.h breaks MPI](#include_mpi_order)
284 - [With Sun C compiler, 64-bit ncdump fails](#suncc-m64-ncdump)
285 - [Portland Group compilers can't build shared fortran 90 or shared
286 C++ library, or 64-bit C++ API](#PG_shared)
287 - [Intel 10.1 64-bit C++ compiler problem](#intel_10.1_64_bit_c++)
288 - [Intel 9.1 C++ compiler problem doesn't build C++
289 API](#intel_9.1__c++)
290 - [ncgen/ncdump test failure with Intel version 11
291 compilers](#intel_11-ncgen)
292 - ["ncdump -v group/var" reports "group not found"](#ncdump-v)
294 ### Including mpi.h before netcdf.h breaks MPI
296 Luis Kornblueh reports a subtle bug in netcdf 4.0.1. In the netcdf.h
297 header file, the following mpi entities are defined:
299 /* These defs added by netCDF configure because parallel HDF5 is not
303 #define MPI_COMM_WORLD 0
304 #define MPI_INFO_NULL 0
306 If mpi.h is included before netcdf.h, these defines (may) break the MPI
309 ### With Sun C compiler, 64-bit ncdump fails
311 As identified by Udo Grabowski, using the "-m64" option to build netCDF
312 with the Sun C compiler results in a failed test when running "make
313 check" in the ncdump directory:
315 *** checking that test1.cdl and test2.nc are the same...
317 < 8.88178419700125e-16, 1.11022302462516e-15, 1.33226762955019e-15,
318 < 1.55431223447522e-15, 1.77635683940025e-15, 222044604925031 ;
320 > 1.97215226305253e-31, 2.46519032881567e-31, 2.9582283945788e-31,
321 > 3.45126646034193e-31, 3.94430452610506e-31, 0.0493038065763132 ;
324 This bug is fixed in recent Sun C compiler releases, for example "Sun C
325 5.11 SunOS\_i386 Aten 2010/05/10".
327 Short of upgrading the compiler, other workarounds include specifying
331 before rerunning the configure script, to turn off optimization, or just
332 install an ncdump built without "-m64". Because ncdump reads only a
333 little data at a time, there is no benefit to a 64-bit ncdump. The
334 32-bit ncdump handles classic, 64-bit offset, and netCDF-4 files
335 correctly even if they are larger than 4 GiB.
337 ### Portland Group compilers can't build shared fortran 90 library or shared C++ library
339 The portland group compilers can't build netCDF shared fortran 90
340 library. They fail with this error:
342 pgf90 -I../fortran -I../f90 -I../libsrc -I../fortran -I../f90
343 -g -c -o tst_f90.o tst_f90.f90
344 /bin/sh ../libtool --mode=link pgf90 -I../fortran -I../f90 --
345 ---I../libsrc -I../fortran -I../f90 -g -L/lib --
346 ---o tst_f90 tst_f90.o ../fortran/libnetcdff.la --
347 ---lm ../libsrc/libnetcdf.la
348 libtool: link: pgf90 -I../fortran -I../f90 -I../libsrc -I../fortran
349 -I../f90 -g -o .libs/tst_f90 tst_f90.o -L/lib
350 ../fortran/.libs/libnetcdff.so -lm ../libsrc/.libs/libnetcdf.so
352 -Wl,/machine/netcdf/n362_test_9456/netcdf-3.6.3-snapshot2008081305/install/lib
353 tst_f90.o:(.debug_info+0x135d): undefined reference to
355 tst_f90.o:(.debug_info+0x136e): undefined reference to `..Dm_netcdf'
357 If anyone could shed some light on this, it would be most appreciated.
358 Send comments to support-netcdf@unidata.ucar.edu.
360 The C++ compiler chokes on the netCDF C++ tests on a shared build:
362 pgCC -DHAVE_CONFIG_H -I. -I.. -I../fortran -I../libdap
363 -I../libsrc -g -c -o tst_failure.o tst_failure.cpp
364 /bin/sh ../libtool --tag=CXX --mode=link pgCC -g -o tst_failure
365 tst_failure.o ../cxx/libnetcdf_c++.la ../libsrc/libnetcdf.la
366 libtool: link: pgCC -g -o .libs/tst_failure tst_failure.o
367 ../cxx/.libs/libnetcdf_c++.so ../libsrc/.libs/libnetcdf.so
368 -Wl,--rpath -Wl,/usr/local/lib
369 make[2]: Leaving directory `/machine/shecky/n4_new2/cxx'
371 make[2]: Entering directory `/machine/shecky/n4_new2/cxx'
372 C++ runtime abort: internal error: static object marked for
373 destruction more than once
374 /bin/sh: line 4: 8445 Aborted ${dir}$tst
376 C++ runtime abort: internal error: static object marked for
377 destruction more than once
378 /bin/sh: line 4: 8468 Aborted ${dir}$tst
381 There is a problem with the pgCC compiler noted as "Fixed in version
384 C++ runtime abort: internal error: static object marked for
385 destruction more than once
387 here as [Technical Problem Report
388 3809](http://www.pgroup.com/support/tprs_62.htm#t3809).
390 This bug was also previously [reported by a
391 user](http://www.unidata.ucar.edu/support/help/MailArchives/netcdf/msg03783.html).
393 ### Intel 10.1 64-bit C++ compiler problem
395 On my test machine, the intel 10.1 C++ compiler cannot build the netCDF
396 C++ API in 64-bit mode. I get an error like this:
398 make[1]: Entering directory
399 `/machine/netcdf/n362_test_16030/netcdf-3.6.3-snapshot2008081312/cxx'
400 depbase=`echo netcdf.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
401 /bin/sh ../libtool --tag=CXX --mode=compile icpc -DHAVE_CONFIG_H
402 -I. -I.. -I../fortran -I../libdap -I../libsrc
403 -I/opt/intel/cce/10.1.015/include -MT netcdf.lo -MD -MP -MF
404 $depbase.Tpo -c -o netcdf.lo netcdf.cpp &&\
405 mv -f $depbase.Tpo $depbase.Plo
406 libtool: compile: icpc -DHAVE_CONFIG_H -I. -I.. -I../fortran
407 -I../libdap -I../libsrc -I/opt/intel/cce/10.1.015/include -MT
408 netcdf.lo -MD -MP -MF .deps/netcdf.Tpo -c netcdf.cpp -o netcdf.o
409 /usr/include/c++/4.3.0/x86_64-redhat-linux/bits/c++locale.h(94):
410 error: argument of type "__va_list_tag *" is incompatible with
411 parameter of type "char *"
412 const int __ret = __builtin_vsnprintf(__out, __size, __fmt,
416 compilation aborted for netcdf.cpp (code 2)
417 make[1]: *** [netcdf.lo] Error 1
418 make[1]: Leaving directory
419 `/machine/netcdf/n362_test_16030/netcdf-3.6.3-snapshot2008081312/cxx'
420 make: *** [check-recursive] Error 1
422 This is because the Intel C++ compiler has not caught up to the GNU C++
423 compiler, and for some reason that is not clear to me, it is using the
424 header files from gcc.
426 To solve this problem, install an older version of gcc (4.1.2 works in
427 testing at Unidata World Test Center, located at the bottom of a
428 six-mile deep mine shaft.) Put the bin directory at the beginning of
429 your PATH, and the lib (or lib64) directory at the beginning at the
430 LD\_LIBRARY\_PATH. Then rebuild.
432 ### Intel 9.1 C++ compiler problem doesn't build C++ API
434 On my test machine, the intel 9.1 C++ compile fails like this:
436 make nctst tst_failure
437 make[2]: Entering directory
438 `/machine/netcdf/n362_test_16035/netcdf-3.6.3-snapshot2008081312/cxx'
439 depbase=`echo nctst.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
440 icpc -DHAVE_CONFIG_H -I. -I.. -I../fortran -I../libdap
441 -I../libsrc -I/opt/intel/cc/9.1.047/include/c++/ -MT nctst.o -MD -MP
442 -MF $depbase.Tpo -c -o nctst.o nctst.cpp &&\
443 mv -f $depbase.Tpo $depbase.Po
444 /bin/sh ../libtool --tag=CXX --mode=link icpc
445 -I/opt/intel/cc/9.1.047/include/c++/ -o nctst nctst.o
446 ../cxx/libnetcdf_c++.la ../libsrc/libnetcdf.la
447 libtool: link: icpc -I/opt/intel/cc/9.1.047/include/c++/ -o nctst
448 nctst.o ../cxx/.libs/libnetcdf_c++.a ../libsrc/.libs/libnetcdf.a
449 nctst.o: In function `main':
450 nctst.cpp:(.text+0x22e): undefined reference to
451 `std::ios_base::clear(std::_Iosb::_Iostate, bool)'
452 nctst.cpp:(.text+0x290): undefined reference to
453 `std::ios_base::clear(std::_Iosb::_Iostate, bool)'
454 nctst.cpp:(.text+0x3b1): undefined reference to
455 `std::ios_base::clear(std::_Iosb::_Iostate, bool)'
456 nctst.cpp:(.text+0x520): undefined reference to
457 `std::ios_base::clear(std::_Iosb::_Iostate, bool)'
458 nctst.cpp:(.text+0x582): undefined reference to
459 `std::ios_base::clear(std::_Iosb::_Iostate, bool)'
460 nctst.o:nctst.cpp:(.text+0x767): more undefined references to
461 `std::ios_base::clear(std::_Iosb::_Iostate, bool)' follow
462 nctst.o: In function `__sti__$E':
463 nctst.cpp:(.text+0x2cb0): undefined reference to
464 `std::_Winit::_Winit()'
465 nctst.cpp:(.text+0x2cbf): undefined reference to `std::_Winit::~_Winit()'
467 Anyone who can shed light on this should send email to
468 support-netcdf@unidata.ucar.edu.
470 ### ncgen/ncdump test failure with Intel version 11 compilers
472 Ed Anderson reports that the tests of the netcdf-4.0 (and presumable
473 4.0.1 and 3.6.3) package fail with the recently released version 11 of
474 the Intel compilers, producing the error message:
476 *** creating UTF-8 test file tst_utf8.nc...Sorry! Unexpected result, tst_utf8.c, line: 63
477 Sorry! Unexpected result, tst_utf8.c, line: 68
478 Sorry! Unexpected result, tst_utf8.c, line: 72
479 Sorry! Unexpected result, tst_utf8.c, line: 79
480 Sorry! Unexpected result, tst_utf8.c, line: 90
481 Sorry! Unexpected result, tst_utf8.c, line: 92
482 Sorry! Unexpected result, tst_utf8.c, line: 114
483 Sorry! Unexpected result, tst_utf8.c, line: 117
484 Sorry! Unexpected result, tst_utf8.c, line: 119
485 Sorry! Unexpected result, tst_utf8.c, line: 122
486 /bin/sh: line 1: 5216 Segmentation fault ${dir}$tst
489 *** Testing ncgen and ncdump for UTF8 support...
490 *** creating classic offset file with utf8 characters...
491 ncgen: NetCDF: Name contains illegal characters
492 ncgen: NetCDF: Invalid dimension ID or name
493 ncgen: NetCDF: Name contains illegal characters
494 FAIL: run_utf8_tests.sh
495 =========================================
498 Ed also reports this is a compiler problem (which has been reported) and
499 that there is a workaround:
501 ... in libsrc/string.c the test
505 can be changed (in two places) to
507 if(ch < 0x7f || ch == 0x7f) {
509 This was the only change I needed to pass the netcdf-4 tests with Intel
512 ### "ncdump -v group/var" reports "group not found"
514 John Storrs reported a bug using ncdump -v applied to netCDF-4 files, in
515 which an erroneous 'group not found' message was displayed for valid
516 group/var names. This is fixed in the next release, and the fix is also
517 in the [current snapshot
518 release](ftp://ftp.unidata.ucar.edu/pub/netcdf/snapshot/).
520 Known Problems with netCDF 4.0
521 ------------------------------
523 - [Ncdump assumes default fill value for unsigned byte
524 data](#ncdump_ubyte_fill)
525 - [Ncdump of compound type with array field](#compound_array_field)
526 - [Memory leak with VLEN attributes](#mem_leak)
527 - [Error dyld: Symbol not found:
528 _H5P_CLS_FILE_ACCESS_g](#o_problem_mac)
529 - [Bug with multiple unlimited dimensions in one
530 var](#multiple_unlimited)
531 - [Fortran90 interface Using Intel ifort under
532 Cygwin](#ifort-f90-cygwin)
533 - [ncdump bug for filenames beginning with a numeric
534 character](#ncdump-numeric-filename)
535 - [ncgen/ncdump test failure with Intel version 11
536 compilers](#intel_11-ncgen)
538 ### Ncdump assumes default fill value for unsigned byte data
540 The ncdump utility incorrectly assumes a default fill value of "255" for
541 data of unsigned byte type, although no default fill value is assumed
542 for data of type signed byte. There should be no default fill values
543 when reading any byte type, signed or unsigned, because the byte ranges
544 are too small to assume one of the values should appear as a missing
545 value unless a \_FillValue attribute is set explicitly. This bug is
546 fixed in the current snapshot distribution.
548 ### Ncdump of compound type with array field
550 Running the ncdump utility on a file with a compound type with an array
551 field may result in a segmentation violation. A fix is in the current
552 netCDF-4.0 snapshot distribution.
554 ### Memory leak with VLEN attributes
556 We believe there are some memory leaks associated with VLEN attributes
557 in HDF5 1.8.1. This is being addressed by the HDF5 team, and will be
558 fixed by the next HDF5 release.
560 ### Error dyld: Symbol not found: _H5P_CLS_FILE_ACCESS_g
562 On some Macintosh systems here at NetCDF World Test Center, on the
563 hundreth floor of UCAR Tower \#2, the following build error occurs:
565 *** Checking HDF5 enum types.
566 *** Checking simple HDF5 enum type...ok.
567 *** Checking HDF5 enum type missing values...ok.
568 *** Tests successful!
570 dyld: Symbol not found: _H5P_CLS_FILE_ACCESS_g
572 /tmp/n4_sid/netcdf-4.0-snapshot2008042320/libsrc4/.libs/libnetcdf.5.dylib
573 Expected in: flat namespace
576 dyld: Symbol not found: _H5P_CLS_FILE_ACCESS_g
578 /tmp/n4_sid/netcdf-4.0-snapshot2008042320/libsrc4/.libs/libnetcdf.5.dylib
579 Expected in: flat namespace
582 dyld: Symbol not found: _H5P_CLS_FILE_ACCESS_g
584 /tmp/n4_sid/netcdf-4.0-snapshot2008042320/libsrc4/.libs/libnetcdf.5.dylib
585 Expected in: flat namespace
589 This can be caused by the configure script failing to add "-lhdf5" to
590 the link flags in the generated Makefiles. Set LDFLAGS to include
591 "-L/WHERE/HDF5/IS/INSTALLED/lib -lhdf5" and try again.
593 ------------------------------------------------------------------------
595 Bug with multiple unlimited dimensions in one var
597 There is a bug in the 4.0 release related to the lengths of dimensions
598 when more than one unlimited dimension is used in the same variable.
600 The bug is fixed in the latest [netCDF-4 snapshot
601 release](ftp://ftp.unidata.ucar.edu/pub/netcdf/snapshot/netcdf-4-daily.tar.gz).
603 ### Fortran90 interface Using Intel ifort under Cygwin
605 Chris Dallimore reports success in getting the Fortran 90 interface of
606 Version 4.0 to compile under CYGWIN using the Intel ifort compile;
608 1 - Download and unpack netcdf-4.0.tar.gz
610 2 - In configure replace conftest.o and conftestf.o with conftest.
611 $ac_objext and conftest.$ac_objext, I'm Not sure why autoconf doesn't
615 Save http://msinttypes.googlecode.com/svn/trunk/inttypes.h as libsrc/
617 Save ttp://msinttypes.googlecode.com/svn/trunk/stdint.h as libsrc/
620 modify line 43 of libsrc/inttypes_msvc.h
626 4 - in libsrc utf8proc.h at line 79 replaces
636 typedef long ssize_t;
637 typedef unsigned int uint32_t;
640 It looks like configure is checking for ssize_t so there is probably a
641 better way to do this.
644 in libsrc/posixio.c at line 18 replace
646 #ifdef _MSC_VER /* Microsoft Compilers */
654 #ifdef _MSC_VER /* Microsoft Compilers */
656 typedef long ssize_t;
657 typedef unsigned int uint32_t;
663 in putget.m4 at line 24 added
670 ./configure --prefix=/cygdrive/z/cwr/Software/Eclipse/CWRModelSource --
671 disable-examples --disable-cxx --disable-utilities
673 Relevant environment variables
676 FFLAGS=/debug:full /traceback /nologo
677 FCFLAGS=/debug:full /traceback /nologo
678 FCFLAGS_f90=/debug:full /traceback /nologo
681 CPPFLAGS=/D AbsoftProFortran /D _MSC_VER /nologo
683 IFORT_COMPILER10_POSIX=/cygdrive/c/Program Files/Intel/Compiler/
685 VSINSTALLDIR=C:\Program Files\Microsoft Visual Studio 8
686 INTEL_LICENSE_FILE=C:\Program Files\Common Files\Intel\Licenses
687 PROCESSOR_IDENTIFIER=x86 Family 6 Model 15 Stepping 6, GenuineIntel
690 MAKEFLAGS=w -- F90=ifort
691 VS80COMNTOOLS=C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\
692 VSINSTALLDIR_POSIX=/cygdrive/c/Program Files/Microsoft Visual Studio 8
693 F90FLAGS=/debug:full /traceback /nologo
695 MAKEOVERRIDES=${-*-command-variables-*-}
697 VCINSTALLDIR=C:\Program Files\Microsoft Visual Studio 8\VC
698 INTEL_SHARED=C:\Program Files\Common Files\Intel\Shared Files
699 LIB=C:\Program Files\Intel\Compiler\Fortran\10.1.013\Ia32\Lib;C:
700 \Program Files\Microsoft Visual Studio 8\VC\atlmfc\lib;C:\Program Files
701 \Microsoft Visual Studio 8\VC\lib;C:\Program Files\Microsoft Visual
702 Studio 8\VC\PlatformSDK\lib;C:\Program Files\Microsoft Visual Studio
703 \DF98\LIB;C:\Program Files\Microsoft Visual Studio\VC98\LIB
704 IFORT_COMPILER10=C:\Program Files\Intel\Compiler\Fortran\10.1.013
706 VCINSTALLDIR_POSIX=/cygdrive/c/Program Files/Microsoft Visual Studio 8/
709 PATH=/cygdrive/c/Program Files/Intel/Compiler/Fortran/10.1.013/Ia32/
710 Bin:/cygdrive/c/Program Files/Common Files/Intel/Shared Files/Ia32/
711 Bin:/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/IDE:/
712 cygdrive/c/Program Files/Microsoft Visual Studio 8/VC/bin:/cygdrive/c/
713 Program Files/Microsoft Visual Studio 8/Common7/Tools:/cygdrive/c/
714 Program Files/Microsoft Visual Studio 8/Common7/Tools/bin:/cygdrive/c/
715 Program Files/Microsoft Visual Studio 8/VC/PlatformSDK/bin:/cygdrive/c/
716 apache-ant-1.7.0/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/
717 cygdrive/c/Program Files/Microsoft Visual Studio/Common/Tools:/
718 cygdrive/c/Program Files/Microsoft Visual Studio/Common/Msdev98/BIN:/
719 cygdrive/c/Program Files/Microsoft Visual Studio/DF98/BIN:/cygdrive/c/
720 Program Files/Microsoft Visual Studio/VC98/BIN:/cygdrive/c/Sun/SDK/jdk/
721 bin:C:/oraclexe/app/oracle/product/10.2.0/server/bin:/cygdrive/c/
722 WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/
723 Wbem:/cygdrive/c/Program Files/jEdit:/cygdrive/c/Program Files/
724 Microsoft SQL Server/90/Tools/binn/:/cygdrive/c/Program Files/Intel/
725 Compiler/Fortran/10.1.013/IA32/Lib:/cygdrive/c/Program Files/Intel/
726 Compiler/Fortran/10.1.013/EM64T/Lib:/cygdrive/c/Program Files/MATLAB/
727 R2008a/bin:/cygdrive/c/Program Files/MATLAB/R2008a/bin/win32
730 PROCESSOR_ARCHITECTURE=x86
731 PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
732 INTEL_SHARED_POSIX=/cygdrive/c/Program Files/Common Files/Intel/Shared
735 INFOPATH=/usr/local/info:/usr/share/info:/usr/info:
736 PROGRAMFILES=C:\Program Files
738 INCLUDE=C:\Program Files\Intel\Compiler\Fortran
739 \10.1.013\Ia32\Include;C:\Program Files\Microsoft Visual Studio 8\VC
740 \atlmfc\include;C:\Program Files\Microsoft Visual Studio 8\VC
741 \include;C:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK
742 \include;C:\Program Files\Microsoft Visual Studio\DF98\INCLUDE;C:
743 \Program Files\Microsoft Visual Studio\VC98\INCLUDE
748 make will compile but fails on linking
750 libtool: link: ( cd ".libs" && rm -f "libnetcdf2.la" && ln -s "../
751 libnetcdf2.la" "libnetcdf2.la" )
752 /bin/sh ../libtool --tag=CC --mode=link /cygdrive/z/cwr/Software/
753 Eclipse/CWRModelSource/src/external/netcdf_src/netcdf-4.0/compile
754 cl -version-info 4:0:0 -o libnetcdf.la -rpath /cygdrive/z/cwr/
755 Software/Eclipse/CWRModelSource/lib attr.lo ncx.lo putget.lo dim.lo
756 error.lo libvers.lo nc.lo string.lo v1hpg.lo var.lo utf8proc.lo
757 posixio.lo libnetcdf2.la ../fortran/libnetcdff.la
758 libtool: link: warning: undefined symbols not allowed in i686-pc-
759 cygwin shared libraries
760 libtool: link: (cd .libs/libnetcdf.lax/libnetcdf2.lib && ar x "/
761 cygdrive/z/cwr/Software/Eclipse/CWRModelSource/src/external/netcdf_src/
762 netcdf-4.0/libsrc/./.libs/libnetcdf2.lib")
763 libtool: link: (cd .libs/libnetcdf.lax/libnetcdff.lib && ar x "/
764 cygdrive/z/cwr/Software/Eclipse/CWRModelSource/src/external/netcdf_src/
765 netcdf-4.0/libsrc/../fortran/.libs/libnetcdff.lib")
766 .libs/libnetcdff.lax/libnetcdff90.lib/typeSizes.obj: No such file or
769 It looks like the Microsoft LInker doesn't like the GNU lib format.
771 I was however able to compile and link using some static (ie non
772 automake) makefiles that are part of our overall model build
775 ### ncdump bug for filenames beginning with a numeric character
777 The ncdump utility in releases 4.0 and 3.6.3 rejects filenames starting
778 with the digits 0,1 and 2 with an error message such as:
780 ncdump: name begins with space or control-character: 2
782 This bug is fixed in the daily snapshot release and in 4.0.1-beta
783 releases, but a one-line patch to ncdump/dumplib.c (for either
784 netCDF-4.0 or netCDF-3.6.3) is to replace the line
786 if((*cp >= 0x01 && *cp <= 0x32) || (*cp == 0x7f))
788 with the following line instead
790 if((*cp >= 0x00 && *cp <= 0x20) || (*cp == 0x7f))
792 ------------------------------------------------------------------------
794 Known Problems with netCDF 3.6.3
795 --------------------------------
797 - [Building shared libraries on Macintosh with
798 g95 fails.](#g95_mac_shared)
799 - [Building Fortran/C++ shared libraries on AIX fails.](#AIX_shared)
800 - [Building shared libraries on HPUX with native tools results in only
801 static libraries.](#HPUX_shared)
802 - [Can't build shared library with F90 API on IRIX.](#IRIX_f90_shared)
803 - [ncdump bug for filenames beginning with a numeric
804 character](#ncdump-numeric-filename)
806 ------------------------------------------------------------------------
808 ### Can't build shared library with F90 API on IRIX
810 When building shared libraries on out IRIX test system, I got the
813 ld32: FATAL 12 : Expecting n32 objects: /lib/libc.so.1 is o32.
815 Obviously there is some ABI confusion here, but we don't know how to
816 resolve it. Any user who can solve this should email
817 support-netcdf@unidata.ucar.edu so that we can share the method with
820 ------------------------------------------------------------------------
822 Known Problems with netCDF 3.6.2
823 --------------------------------
825 - [Setting ARFLAGS does not work.](#ARFLAGS)
826 - [Bugs in support for variables larger than 4 GiB](#large_vars_362)
827 - [Bug in C++ interface prevents creating 64-bit offset format
829 - [Shared libraries do not work with the NAG
830 fortran compiler.](#nag_362)
831 - [The tests in nf_test fail with seg fault with the Absoft Version
832 10.0 fortran compiler.](#absoft10)
833 - [The documented --enable-64bit option doesn't work](#enable-64bit)
834 - [Building netCDF-3.6.2 with gfortran version
835 4.3.x fails.](#gfortran_43)
836 - [Building shared libraries on Macintosh with
837 g95 fails.](#g95_mac_shared)
838 - [Building shared libraries on HPUX with native tools results in only
839 static libraries.](#HPUX_shared)
840 - [Building Fortran/C++ shared libraries on AIX fails.](#AIX_shared)
841 - [Building with older versions of g++ fails.](#old_gpp)
842 - [The .NET build files are not included in the
843 3.6.2 release.](#NET_3_6_2)
844 - [Snapshot .NET build files do not work for Visual Studio 8.0
845 beta releases.](#NET_80_362)
846 - [The -disable-v2 option causes the fortran build to fail with some
847 fortran compilers.](#disable-v2_3_6_2)
848 - [The --disable-c option does not work.](#disable-c_3_6_2)
850 ------------------------------------------------------------------------
852 ### Setting ARFLAGS does not work
854 Sometimes when building netCDF, flags to the ar utility need to be set.
855 Setting ARFLAGS does not work.
857 (Note: If you are doing this to build 64-bit libraries on an AIX
858 platform, the most fool-proof way to built 64-bit applications under AIX
859 is to set the OBJECT\_MODE environment variable to 64. If you still feel
860 you must setr flags for ar, read on.)
862 Try the build again, setting AR\_FLAGS instead of ARFLAGS.
864 ### Bugs in support for variables larger than 4 GiB
866 As first reported by Mario Emmenlauer, there is a bug in netCDF-3.6.2
867 (and earlier versions) in the code for creating byte and short type
868 variables greater than 4 GiB in size. This problem resulted in an
869 assertion violation or arithmetic exception that would have caused a
870 program to halt, rather than writing bad data or corrupting existing
873 A fix is available as a [patch](../patches/large-vars-362-patch) to the
874 file libsrc/var.c in the netcdf-3.6.2 distribution. The bug is also
875 fixed in releases 3.6.3 and later.
877 1. On 32-bit platforms (with size\_t an unsigned 32-bit type):
878 - For a short variable, if the product of dimensions (not counting
879 the record dimension, if any) is greater than 2^31^ (that's
880 2147483648), the following assertion violation occurs
882 Assertion failed: remaining > 0, file putget.c, line 347
884 - For any type of variable, if the product of dimensions (not
885 counting the record dimension, if any) is exactly 2^32^
886 (that's 4294967296) or any multiple of 2^32^, a divide by zero
889 Arithmetic Exception(coredump)
891 2. On 64-bit platforms (with size\_t an unsigned 64-bit type):
892 - For a byte variable, if the product of dimensions (not counting
893 the record dimension, if any) is greater than 2^32^, an
894 assertion violation occurs
896 Assertion failed: *ulp <= X_SIZE_MAX, file ncx.c, line 1810
898 - For a short variable, if the product of dimensions (not counting
899 the record dimension, if any) is greater than 2^31^, the same
900 assertion violation occurs
902 Assertion failed: *ulp <= X_SIZE_MAX, file ncx.c, line 1810
904 ### Bug in C++ interface prevents creating 64-bit offset format files
906 As reported by Jos Verdoold, a bug in the netCDF 3.6.2 (and earlier
907 versions) C++ interface prevents creating new files in Offset64Bits mode
908 using the C++ API. The fix is to change two lines (378 and 393) in the
909 file src/cxx/netcdf.cpp, changing "=" to "|=" in each line, then
917 < mode = NC_NOCLOBBER;
919 > mode |= NC_NOCLOBBER;
921 This fix has been incorporated into netCDF 3.6.3 and later versions.
923 ### The tests in nf\_test fail with seg fault with the Absoft Version 10.0 fortran compiler.
925 The absoft fortran compiler, version 10.0, changes the way that a C
926 function returning string is called from fortran.
928 This causes the absoft fortran settings in cfortran.h to no longer work,
929 and this is reflected in a segmentation fault in the test program
932 As a workaround, users with absoft version 10 can get the latest
933 netCDF-3 snapshot and build it with the --enable-absoft10-hack option
936 Get the snapshot, and see the working output, on the [netCDF-3
937 snapshot](http://www.unidata.ucar.edu/software/netcdf/builds/snapshot/)
940 ### Shared libraries do not work with the NAG fortran compiler.
942 We have reports that the shared library build does not work with the NAG
943 fortran compiler. The NAG compiler is not one of the compilers we
944 current support (and test on) at Unidata. The only known work around is
945 to build without the --enable-shared option.
947 Any user who can debug this problem with the NAG compiler should send
948 the resuts to support-netcdf@unidata.ucar.edu, so that it can be
949 incorporated into the netCDF distribution.
951 Interested users may also wish to subscribe to the [netcdf-porting
953 list](http://www.unidata.ucar.edu/mailing_lists/archives/netcdf-porting/).
955 ### The documented --enable-64bit option doesn't work.
957 The --enable-64bit option appeared in the 3.6.1 release, and was--
958 removed for the 3.6.2 release.
960 Unfortunately, the documentation was not updated, so that the 3.6.2
961 documentation still mentions the enable-64bit option. Sorry about that.
963 The documentation has been corrected for the [netCDF-3
964 snapshot](http://www.unidata.ucar.edu/software/netcdf/builds/snapshot/)
966 snapshot](http://www.unidata.ucar.edu/software/netcdf/builds/snapshot/index_4.html)
969 ### Building netCDF-3.6.2 with gfortran version 4.2.x or 4.3.x fails.
971 Something changed in gfortran version 4.3 relating to how fortran
972 functions can call C functions.
974 In netCDF, the interface between C and Fortran is handled by the
975 cfortran.h package, which requires a pre-processor define describing the
976 type of fortran you are using.
978 For gfortran up to version 4.1.x, the netCDF distribution builds cleanly
979 with the "gFortran" preprocessor symbol set. For gfortran 4.2.x and
980 greater, the "pgiFortran" preprocessor symbol works.
982 The 3.6.2 build uses "gFortran", unless you specifically set the
983 CPPFLAGS environmental variable to "-DpgiFortran".
985 This works in my bash shell:
987 FC=gfortran CPPFLAGS=-DpgiFortran ./configure && make check
989 This problem has been fixed in the [netCDF-3
990 snapshot](../builds/snapshot). Now configure checks the version of
991 gfortran before setting the appropriate flag.
993 ### Building shared libraries on Macintosh with g95 fails.
995 Building shared libraries on the Macintosh fails
998 *** Testing netCDF-3 Fortran 90 API.
999 dyld: lazy symbol binding failed: Symbol not found: __g95_size
1001 /tmp/n3_mort/netcdf-3.6.2-snapshot2007052501/fortran/.libs/libnetcdff.4.dylib
1002 Expected in: flat namespace
1004 dyld: Symbol not found: __g95_size
1006 /tmp/n3_mort/netcdf-3.6.2-snapshot2007052501/fortran/.libs/libnetcdff.4.dylib
1007 Expected in: flat namespace
1010 =========================================
1012 Please report to support@unidata.ucar.edu
1013 =========================================
1015 ### Building shared libraries on HPUX with native tools results in only static libraries.
1017 On the only HPUX machine I have access to for testing, the
1018 --enable-shared still results in only the static library being linked.
1020 This may be because of and old C++ compiler on this particular platform.
1021 Any HPUX use who can provide information about this should send email to
1022 support-netcdf@unidata.ucar.edu. bash-2.04\$ uname -a HP-UX tweety
1023 B.11.00 A 9000/785 2004553471
1025 ### Building shared libraries on AIX fails.
1027 On the Unidata AIX platforms, the shared netCDF build fails with either
1028 the Fortran or C++ compilers, like this:
1031 *** Creating fills.nc.
1033 PASS: create_fills.sh
1034 /bin/sh: 16012 Segmentation fault(coredump)
1036 /bin/sh: 16018 Segmentation fault(coredump)
1038 /bin/sh: 16024 Segmentation fault(coredump)
1040 =========================================
1042 Please report to support@unidata.ucar.edu
1043 =========================================
1045 If built without fortran or C++, the build succeeds, but shared
1046 libraries are not built. (Static libraries are).
1048 I don't know what is causing this. If any AIX users can shed any light,
1049 that would be most helpful.
1051 Shared builds also fail the same way when using GNU compilers.
1053 ### Building with older versions of g++ fails.
1055 The build fails like this:
1057 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
1058 In file included from /opt/gnu/gcc/include/c++/3.2/powerpc-ibm-aix5.0.0.0/bits/c++io.h:35,
1059 from /opt/gnu/gcc/include/c++/3.2/bits/fpos.h:44,
1060 from /opt/gnu/gcc/include/c++/3.2/iosfwd:46,
1061 from /opt/gnu/gcc/include/c++/3.2/ios:44,
1062 from /opt/gnu/gcc/include/c++/3.2/ostream:45,
1063 from /opt/gnu/gcc/include/c++/3.2/iostream:45,
1065 /opt/gnu/gcc/include/c++/3.2/cstdio:108: `fgetpos' not declared
1066 /opt/gnu/gcc/include/c++/3.2/cstdio:110: `fopen' not declared
1067 /opt/gnu/gcc/include/c++/3.2/cstdio:115: `freopen' not declared
1068 /opt/gnu/gcc/include/c++/3.2/cstdio:118: `fsetpos' not declared
1069 netcdf.cpp: In member function `NcBool NcVar::set_cur(long int, long int, long
1070 int, long int, long int)':
1072 This happens in old versions of g++ when large files are used. To fix
1073 this, either upgrade your g++ compiler, or else use --disable-largefile
1074 with configure, to turn off large file handling.
1076 ### The .NET build files are not included in the 3.6.2 release.
1078 The netCDF 3.6.2 release does not contain the .NET build files. Whoops!
1081 .NET users should use the latest snapshot, or continue to use the 3.6.1
1084 This is now fixed in the netCDF-3 snapshot. Get the snapshot from the
1085 [netCDF-3 snapshot build page](../builds/snapshot).
1087 ### Snapshot .NET build files do not work for Visual Studio 8.0 beta.
1089 A user has reported that Visual Studio .NET version 8.0 beta does not
1090 build with the netCDF .NET build files in win32/NET.
1092 Interested users may also wish to subscribe to the [netcdf-porting
1094 list](http://www.unidata.ucar.edu/mailing_lists/archives/netcdf-porting/).
1096 ### The -disable-v2 option causes the fortran build to fail with some fortran compilers.
1098 The netCDF version 2 API is maintained for backward compatibility. We
1099 are committed to maintaining the V2 API for all future releases of
1100 netCDF. However, the --disable-v2 option is provided -- for users who
1101 wish to compile the netCDF libraries without the V2 API.
1103 The --disable-v2 option will cause the fortran build to fail on some
1104 fortran 95 compilers because the netcdf.inc file still includes the
1105 names of the V2 API functions. (Other fortran 90 compilers ignore
1108 If your compiler fails with --disable-v2, you can either refrain from
1109 using this option (that is, build the v2 API as well as the V3 API), or
1110 you can get the netCDF-3 [snapshot](../builds/snapshot).
1112 This is fixed for future releases of netCDF.
1114 ### The --disable-c option does not work.
1116 The --disable-c option should turn off the building of the netCDF C
1117 library for use with --enable-separate-fortran (to save a small amount
1118 of tme building and testing. However this does not happen. The C library
1119 is built in any case.
1121 Users may ignore this option in version 3.6.2. It is fixed in the
1122 netCDF-3 [snapshot](../builds/snapshot) and for future releases of
1125 Known Problems with netCDF 3.6.1
1126 --------------------------------
1128 [Building on IBM Bluegene login node (SUSE Linux)](#login_node_3_6_1)
1130 [Linux x86 Fedora4 with Intel ifort 9.0 compiler](#ifort_3_6_1)
1132 ### Building on IBM Bluegene login node (SUSE Linux)
1134 Michael McCracken reports the following:
1136 Hi, I have been working with netcdf and parallel netcdf on
1137 bluegene at SDSC. I have no problems building a version to link with
1138 WRF and run on the ppc32 compute nodes.
1140 When I need to inspect a data file, I can't run the ncdump that is
1141 built with the cross-compiling configure without running it on a
1142 compute node. It works, but I end up waiting in the queue (and being
1143 charged for using 64 CPUs).
1145 I'd like to build an ncdump that works on the login node, and I was
1146 wondering if anyone had done that on a bluegene yet. The local staff
1149 Here's how I did it:
1151 After some debugging, I can configure and compile with the following
1154 I added -DIBMR2Fortran because apparently that's not getting set on
1155 bluegene (probably because it's linux and not AIX), and without it
1156 compiling in the fortran/ subdir barfs.
1159 setenv CFLAGS "-O3 -qstrict -DIBMR2Fortran"
1162 setenv CXXFLAGS "-O3 -qstrict"
1163 setenv CXXCPP "xlC -E"
1167 setenv FFLAGS "-O3 -qstrict"
1169 ./configure --disable-flag-setting
1171 I get a clean build, and ncdump works for me...
1173 ### Linux x86 Fedora4 with Intel ifort 9.0 compiler
1175 For netCDF version 3.6.1, Jonathan Rougier contributes the following
1176 work around for an intel fortran compiler bug.
1178 There is a bug (which may have been fixed: see the ifort pages), which
1179 generates an error message along the lines of:
1181 IPO link: can not find "("
1182 ifort: error: problem during multi-file optimization compilation (code
1185 The documented cludge, which worked for me, is:
1190 setenv FFLAGS "-mp -recursive"
1191 setenv CPPFLAGS "-DNDEBUG -DpgiFortran"
1195 echo null > \(; echo null > AS_NEEDED
1196 echo null > nf_test/\(; echo null > nf_test/AS_NEEDED
1197 echo null > ncgen/\(; echo null > ncgen/AS_NEEDED
1199 which creates files called '(' and AS\_NEEDED in the appropriate places.
1201 ------------------------------------------------------------------------
1205 Known Problems with netCDF 3.6.0
1206 --------------------------------
1208 - [nctest fails on IRIX platform](#irix-nctest)
1209 - [C++ API doesn't build on Irix](#irix-CXX-build)
1210 - [Potentially serious bug with 64-bit offset files](#cdf2-bug)
1211 - [Cygwin build doesn't work](#bad-cygwin)
1212 - [Windows DLL doesn't include F77 API](#dll-fortran)
1213 - [F90 tests fail with Portland F90 compiler](#portland-f90)
1214 - [Config doesn't find working F77 or F90 compiler on
1216 - [F90 functions not added to library on AIX](#aix-make)
1217 - [Problems with fortran compile because of -Df2cFortran being added
1218 by configure](#fortran-config)
1219 - [Message: "ncgenyy.c is out-of-date with respect to
1220 ncgen.l"](#ncgen-timestamp)
1221 - [Configure help specifies FCFLAGS instead of FFLAGS](#fcflags)
1222 - [Specifying an edge-length of zero returns error instead of no
1224 - [C++ library doesn't build under Cygwin](#cygwincpp)
1225 - [Large file problems in Visual C++ compile](#visualcpp_largefile)
1226 - [When using TEMP_LARGE, need a trailing slash](#temp_large)
1228 ------------------------------------------------------------------------
1230 ### nctest fails on IRIX platform
1232 It has been reported (by Atro Tossavainen) that nctest fails on some
1233 Irix builds. (We cannot duplicate this problem at netCDF World HQ).
1235 The nctest fails when comparing the test-generated out with a saved copy
1238 This problem was fixed in the 3.6.1 release.
1240 ### C++ API doesn't build on Irix
1242 On Irix systems without a recent version of the C++ compiler, the C++
1243 API won't build. The solution is to set CXXFLAGS to -LANG:std.
1245 ### Potentially serious bug with 64-bit offset files
1247 Kevin Thomas of the University of Oklahoma has reported a potentially
1248 serious bug in using the new large file support in netCDF 3.6.0. Users
1249 of the new large file facilities are cautioned to either apply [this
1250 one-line patch to netCDF
1251 3.6.0](/software/netcdf/patches/patch-3.6.0-cdf2) or to upgrade from
1252 version 3.6.0 to the current release version 3.6.0-p1, available from
1253 [netcdf.tar.Z](ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf.tar.Z) or
1254 [netcdf.tar.gz](ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf.tar.gz).
1255 Until you can upgrade, avoid rewriting in place any large (> 2 GiB)
1256 netCDF files that use the new 64-bit offset format under the conditions
1259 The bug occurs following this sequence of steps:
1261 A large netCDF file is created using the new 64-bit offset format
1262 variant (also known as the version 2 format) and the file is closed.
1264 Later the file is opened for writing, followed by either of the
1265 following operations:
1267 - enter define mode (calling nc\_redef(), nf\_redef(), or
1268 nf90\_redef(), in C, Fortran-77, or Fortran-90 interface,
1269 for example) to add a new dimension, variable, or attribute; or
1270 - write a new value for an existing attribute (either a global or a
1271 variable-specific attribute).
1273 Under these conditions, after you leave define mode or close the file,
1274 the file header is written out in the "classic" (version 1) netCDF
1275 format, chopping the leading bits off any variable offsets that were
1276 large enough to require more than 32 bits. If there were no such huge
1277 variable offsets, the file is undamaged and remains readable as a
1278 classic netCDF file. If there were any huge variable offsets (> 2
1279 GiB), data for the first such variable and all subsequent variables will
1280 not be accessed correctly. It is possible to restore the header for such
1281 a file to the correct 64-bit offset form so that the data can
1282 subsequently be accessed correctly, if no data values have been
1283 overwritten since the file header was changed to classic format. Feel
1284 free to [contact us](mailto:support-netcdf@unidata.ucar.edu) for help
1285 restoring the file headers if this applies to you. If you have any large
1286 64-bit offset format netCDF files that might have mistakenly been
1287 rewritten with classic format headers, please be careful not to write
1288 any more data into them, as it could overwrite data that could not
1289 subsequently be recovered.
1291 If you want to know how to tell if a 64-bit offset file has been
1292 converted by this bug into a classic format file, see the answer to the
1293 FAQ [How can I tell if a netCDF file uses the classic format or new
1295 format?](/software/netcdf/faq.html#Large%20File%20Support5).
1297 ### Cygwin Build Doesn't Work
1299 To build on Cygwin, you must get the [latest 3.6.1 beta
1300 release](ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-beta.tar.gz).
1302 ### Windows DLL doesn't include F77 API
1304 The netCDF windows DLL doesn't include the Fortran API. We are working
1305 on this problem for the next release. Meanwhile, if you need the fortran
1306 API in your DLL, you'll have to use the [netCDF 3.5.1
1307 DLL](ftp://ftp.unidata.ucar.edu/pub/netcdf/contrib/win32/netcdf-3.5.1-win32dll.zip).
1309 ### F90 tests fail with Portland F90 compiler
1311 On some versions of the Portland Group F90 compiler, the F90 tests fail,
1312 looking something like this:
1316 *** example_good.cdl 2000-04-05 21:33:14.000000000 +0200
1317 --- example.cdl 2005-01-11 10:21:31.624884000 +0100
1328 lat = -90, -87.5, -85, -82.5 ;
1339 This problem is caused by a bug in the Portland F90 compiler. Upgrade to
1340 the latest version of the compiler or get the free patch from Portland
1343 ### Config doesn't find working F77 or F90 compiler on AIX
1345 On AIX systems, the configure step can't find either the F90 or the F77
1346 compiler. On AIX system, you must set the environment variables FC and
1347 F90 to xlf and xlf95.
1349 ### xlf90 fails to compile test program during configure on AIX
1351 On AIX systems, the F90 option -qsuffix=f=f90 is required in F90FLAGS.
1352 Configure should automatically detect and add this to F90FLAGS if it's
1353 not already there, but it doesn't.
1355 FIX: Make sure that -qsuffix=f=f90 is set in the F90FLAGS before running
1358 This will be fixed in the next beta release.
1360 ### F90 functions not added to library on AIX
1362 On AIX systems, the F90 functions may not be added to the library. This
1363 is due to a quirk of AIX make.
1365 Before doing "make install", change to the Fortran90 directory (src/f90)
1366 and do "make". Then proceed to "make install".
1368 ### Problems with fortran compile because of -Df2cFortran being added by configure"
1370 With some fortran compilers, such as Absoft, the configure script
1371 stupidly adds a -Df2cFortran to the C preprocessor flags, which causes
1372 the fortran tests in nf\_test to fail to link.
1374 This problem is fixed in the 3.6.1 beta release. Get the [3.6.1 beta
1375 release](ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-beta.tar.Z).
1377 ### Message: "ncgenyy.c is out-of-date with respect to ncgen.l"
1379 On some platforms (HP-UX 11.00, maybe others), make fails with an error
1382 Warning: ncgenyy.c is out-of-date with respect to ncgen.l
1383 Warning: It should be recreated via flex on a SunOS 5 system
1385 and then fails if the "flex" command is not found.
1387 The problem is that the modification time on the source file
1388 src/ncgen/ncgenyy.c is being interpreted as earlier than the
1389 modification time on the source file src/ncgen/ncgen.l, even though
1390 ncgenyy.c was actually created after ncgen.l was modified. To workaround
1391 this problem on a Unix system, run the following command from the netCDF
1392 src/ directory to update the modification time of the derived file:
1394 touch ncgen/ncgenyy.c
1396 Then rerun the make command.
1398 ### Configure help specifies FCFLAGS instead of FFLAGS
1400 If you run "configure --help", it suggests setting "FCFLAGS" for the
1401 fortran compiler flags, but "FFLAGS" is actually used for the Fortran
1402 compiler flags. "FCFLAGS" is ignored when compiling.
1404 This problem will be is fixed in the next beta release. Until then, use
1405 FFLAGS, not FCFLAGS.
1407 ### Specifying a count length of zero returns an error instead of no data
1409 For access to array sections, strided access, or mapped access, you need
1410 to specify both a start index vector and a count vector, where the count
1411 vector specifies the number of slices along each edge to access. If the
1412 start index vector specifies the maximum dimension size and the
1413 corresponding count vector is zero, the library should just return no
1414 data, but instead it returns an error status indicating "Index exceeds
1415 dimension bound". This problem has been present in all versions of
1416 netCDF, and the test programs even verify that in this case an error is
1417 returned rather than gracefully accessing no data.
1419 This will be fixed in the next minor version.
1421 ### C++ library doesn't build under Cygwin
1423 Running configure on Cygwin fails to find GNU C++ compiler, even if it
1424 is present on the platform. As a result, the C++ interface is never
1427 This problem is fixed in the 3.6.1 beta release. Cygwin users interested
1428 in the C++ interface should get the [3.6.1 beta
1429 release](ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-3.6.1-beta1.tar.Z).
1431 ### Large file problems in Visual C++ compile
1433 The use of large files, and an 8-byte off\_t type, is not handled
1434 correctly in the 3.6.0 release of the code and project files needed to
1435 compile the netCDF library with Visual C++.NET.
1437 This problem is fixed in the 3.6.1 beta release. Users interested in
1438 building their own DLL should get the [3.6.1 beta
1439 release](ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-3.6.1-beta1.tar.Z).
1440 The DLL offered on the binary release page is 3.6.1 beta.
1442 ### When using TEMP\_LARGE, need a trailing slash
1444 When using the environment variable TEMP\_LARGE during the netCDF 3.6.0
1445 make extra\_test phase, the directory name must be followed by a slash
1446 to work. For example, use 'setenv TEMP\_LARGE /tmp/' instead of 'setenv
1447 TEMP\_LARGE /tmp', as one would usually expect, and as the documentation
1450 This problem is fixed in the [3.6.1 beta
1451 release](ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-3.6.1-beta1.tar.Z).
1452 Users of 3.6.0 should specify the trailing slash to use the TEMP\_LARGE
1453 environment variable in make extra\_test.
1455 ------------------------------------------------------------------------
1457 Reported problems and workarounds are also available for some previous
1458 releases: [version 3.5](/software/netcdf/known_problems_35.html),
1459 [version 3.4](/software/netcdf/known_problems_34.html), [version
1460 3.3.1](/software/netcdf/known_problems_331.html), [version
1461 3.3](/software/netcdf/known_problems_330.html), [version
1462 2.4.3](/software/netcdf/known_problems_243.html), and [version
1463 2.4.2](/software/netcdf/known_problems_242.html).