NetCDF  4.6.3
 All Data Structures Files Functions Variables Typedefs Macros Modules Pages
known_problems.md
1 # Known Problems with netCDF {#known_problems}
2 
3 
4 Known Problems with netCDF 4.3.0
5 --------------------------------
6 
7 - [clang compiler (default on OSX 10.9 Mavericks) detects error
8  building ncgen3](#clang-ncgen3)
9 
10 Known Problems with netCDF 4.2
11 ------------------------------
12 
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
16  work](#with-hdf5)
17 
18 Known Problems with netCDF 4.1.3
19 --------------------------------
20 
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)
28 
29 Known Problems with netCDF 4.1.2
30 --------------------------------
31 
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)
35 
36 Known Problems with netCDF 4.1.1
37 --------------------------------
38 
39 - [Ncgen is known to produce bad output and should not
40  be used.](#bad-ncgen)
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
44  command](#texi2dvi)
45 - [Accessing a multidimensional variable with more than 4 billion
46  values on a 32-bit platform](#big-mvar-32bit)
47 
48 ------------------------------------------------------------------------
49 
50 ### The clang compiler (default on OSX 10.9 Mavericks) detects error building ncgen3
51 
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
55 
56  #include <config.h>
57 
58 above the "`#include <stdlib.h>`" statement near the beginning of
59 ncgen3/genlib.h.
60 
61 This fix will be in the next release.
62 
63 ### Fortran options of nc-config utility (--fflags, --flibs, --has-f90) don't work correctly
64 
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.
71 
72 ### Using "--with-hdf5=..." configure option doesn't seem to work
73 
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
77 
78  CPPFLAGS=-I/usr/local/hdf5/include LDFLAGS=-L/usr/local/hdf5/lib ./configure
79 
80 The reason for this change is explained
81 [here](https://www.unidata.ucar.edu/jira/browse/NCF-20).
82 
83 ### nccopy -d and -c options for compression and chunking don't work on netCDF-4 input files
84 
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
91 issue tracker.
92 
93 The bug has been fixed in all releases since 4.1.3, including the
94 netcdf-4.2-rc1 release candidate.
95 
96 ### Debug statement left in F90 source
97 
98 The debugging statement
99 
100  print *, values(1, 1), values(1, 2), values(1, 3), values(1, 4)
101 
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.
106 
107 ### Ncgen is known to produce bad output.
108 
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
111 should not be used.
112 
113 ### Building with Intel Fortran on Mac OS X
114 
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:
120 
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
124  make check
125 
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.)
129 
130 ### Accessing OPeNDAP servers using a constraint expression
131 
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
136 in the error message
137 
138  NetCDF: Malformed or inaccessible DAP DDS
139 
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).
143 
144 ### Configuring with "--enable-benchmarks" option
145 
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.
149 
150 ### Problem with disabling fill mode when using Lustre (or other large blksize file system)
151 
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.
157 
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.
161 
162 An example that failed depended on all the following circumstances:
163 
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.
176 
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
182 netCDF.
183 
184 ### "make check" fails when linked with HDF5-1.8.6
185 
186 When built with HDF5 version 1.8.6, version 4.1.1 fails one of the tests
187 invoked by "make check":
188 
189  ...
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
194  major: Symbol table
195  minor: Object not found
196  #001: H5Gloc.c line 591 in H5G_loc_find_by_idx(): can't find object
197  major: Symbol table
198  minor: Object not found
199  ...
200  PASS: tst_endian_fill
201  ================================================
202  1 of 59 tests failed
203  Please report to support-netcdf@unidata.ucar.edu
204  ================================================
205  make[2]: *** [check-TESTS] Error 1
206 
207 Currently the workarounds are to either
208 
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
211 
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>.
215 
216 ### Make tries to regenerate documentation with texi2dvi command
217 
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
220 command is reported:
221 
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
228 
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).
233 
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.
240 
241 ### Accessing a multidimensional variable with more than 4 billion values on a 32-bit platform
242 
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
247 conditions are met:
248 
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
260  more than 17 Gbytes.
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.
264 
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
268 case of a write.
269 
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
272 statement
273 
274  lcoord += *up * *ip;
275 
276 with
277 
278  lcoord += (off_t)(*up) * (off_t)(*ip);
279 
280 Known Problems with netCDF 4.0.1
281 --------------------------------
282 
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)
293 
294 ### Including mpi.h before netcdf.h breaks MPI
295 
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:
298 
299  /* These defs added by netCDF configure because parallel HDF5 is not
300  present. */
301  #define MPI_Comm int
302  #define MPI_Info int
303  #define MPI_COMM_WORLD 0
304  #define MPI_INFO_NULL 0
305 
306 If mpi.h is included before netcdf.h, these defines (may) break the MPI
307 implementation.
308 
309 ### With Sun C compiler, 64-bit ncdump fails
310 
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:
314 
315  *** checking that test1.cdl and test2.nc are the same...
316  62,63c62,63
317  < 8.88178419700125e-16, 1.11022302462516e-15, 1.33226762955019e-15,
318  < 1.55431223447522e-15, 1.77635683940025e-15, 222044604925031 ;
319  ---
320  > 1.97215226305253e-31, 2.46519032881567e-31, 2.9582283945788e-31,
321  > 3.45126646034193e-31, 3.94430452610506e-31, 0.0493038065763132 ;
322  FAIL: run_tests.sh
323 
324 This bug is fixed in recent Sun C compiler releases, for example "Sun C
325 5.11 SunOS\_i386 Aten 2010/05/10".
326 
327 Short of upgrading the compiler, other workarounds include specifying
328 
329  CFLAGS="-O0 -m64"
330 
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.
336 
337 ### Portland Group compilers can't build shared fortran 90 library or shared C++ library
338 
339 The portland group compilers can't build netCDF shared fortran 90
340 library. They fail with this error:
341 
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
351  -Wl,-rpath
352  -Wl,/machine/netcdf/n362_test_9456/netcdf-3.6.3-snapshot2008081305/install/lib
353  tst_f90.o:(.debug_info+0x135d): undefined reference to
354  `..Dm_typesizes'
355  tst_f90.o:(.debug_info+0x136e): undefined reference to `..Dm_netcdf'
356 
357 If anyone could shed some light on this, it would be most appreciated.
358 Send comments to support-netcdf@unidata.ucar.edu.
359 
360 The C++ compiler chokes on the netCDF C++ tests on a shared build:
361 
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'
370  make check-TESTS
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
375  FAIL: nctst
376  C++ runtime abort: internal error: static object marked for
377  destruction more than once
378  /bin/sh: line 4: 8468 Aborted ${dir}$tst
379  XFAIL: tst_failure
380 
381 There is a problem with the pgCC compiler noted as "Fixed in version
382 6.2.1" described as
383 
384  C++ runtime abort: internal error: static object marked for
385  destruction more than once
386 
387 here as [Technical Problem Report
388 3809](http://www.pgroup.com/support/tprs_62.htm#t3809).
389 
390 This bug was also previously [reported by a
391 user](http://www.unidata.ucar.edu/support/help/MailArchives/netcdf/msg03783.html).
392 
393 ### Intel 10.1 64-bit C++ compiler problem
394 
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:
397 
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,
413  __args);
414  ^
415 
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
421 
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.
425 
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.
431 
432 ### Intel 9.1 C++ compiler problem doesn't build C++ API
433 
434 On my test machine, the intel 9.1 C++ compile fails like this:
435 
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()'
466 
467 Anyone who can shed light on this should send email to
468 support-netcdf@unidata.ucar.edu.
469 
470 ### ncgen/ncdump test failure with Intel version 11 compilers
471 
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:
475 
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
487  FAIL: tst_utf8
488 
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  =========================================
496  2 of 8 tests failed
497 
498 Ed also reports this is a compiler problem (which has been reported) and
499 that there is a workaround:
500 
501  ... in libsrc/string.c the test
502 
503  if(ch <= 0x7f) {
504 
505  can be changed (in two places) to
506 
507  if(ch < 0x7f || ch == 0x7f) {
508 
509  This was the only change I needed to pass the netcdf-4 tests with Intel
510  version 11.
511 
512 ### "ncdump -v group/var" reports "group not found"
513 
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/).
519 
520 Known Problems with netCDF 4.0
521 ------------------------------
522 
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)
537 
538 ### Ncdump assumes default fill value for unsigned byte data
539 
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.
547 
548 ### Ncdump of compound type with array field
549 
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.
553 
554 ### Memory leak with VLEN attributes
555 
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.
559 
560 ### Error dyld: Symbol not found: _H5P_CLS_FILE_ACCESS_g
561 
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:
564 
565  *** Checking HDF5 enum types.
566  *** Checking simple HDF5 enum type...ok.
567  *** Checking HDF5 enum type missing values...ok.
568  *** Tests successful!
569  PASS: tst_h_enums
570  dyld: Symbol not found: _H5P_CLS_FILE_ACCESS_g
571  Referenced from:
572  /tmp/n4_sid/netcdf-4.0-snapshot2008042320/libsrc4/.libs/libnetcdf.5.dylib
573  Expected in: flat namespace
574 
575  FAIL: tst_lists
576  dyld: Symbol not found: _H5P_CLS_FILE_ACCESS_g
577  Referenced from:
578  /tmp/n4_sid/netcdf-4.0-snapshot2008042320/libsrc4/.libs/libnetcdf.5.dylib
579  Expected in: flat namespace
580 
581  FAIL: tst_dims
582  dyld: Symbol not found: _H5P_CLS_FILE_ACCESS_g
583  Referenced from:
584  /tmp/n4_sid/netcdf-4.0-snapshot2008042320/libsrc4/.libs/libnetcdf.5.dylib
585  Expected in: flat namespace
586 
587  etc.
588 
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.
592 
593 ------------------------------------------------------------------------
594 
595 Bug with multiple unlimited dimensions in one var
596 
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.
599 
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).
602 
603 ### Fortran90 interface Using Intel ifort under Cygwin
604 
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;
607 
608  1 - Download and unpack netcdf-4.0.tar.gz
609 
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
612  do this.
613 
614  3 -
615  Save http://msinttypes.googlecode.com/svn/trunk/inttypes.h as libsrc/
616  inttypes_msvc.h
617  Save ttp://msinttypes.googlecode.com/svn/trunk/stdint.h as libsrc/
618  stdint_msvc.h
619 
620  modify line 43 of libsrc/inttypes_msvc.h
621  from
622  #include
623  to
624  #include
625 
626  4 - in libsrc utf8proc.h at line 79 replaces
627 
628  #include
629 
630  with
631 
632  #ifndef _MSC_VER
633  #include
634  #else
635  #include
636  typedef long ssize_t;
637  typedef unsigned int uint32_t;
638  #endif
639 
640  It looks like configure is checking for ssize_t so there is probably a
641  better way to do this.
642 
643  5 -
644  in libsrc/posixio.c at line 18 replace
645 
646  #ifdef _MSC_VER /* Microsoft Compilers */
647  #include
648  #else
649  #include
650  #endif
651 
652  with
653 
654  #ifdef _MSC_VER /* Microsoft Compilers */
655  #include
656  typedef long ssize_t;
657  typedef unsigned int uint32_t;
658  #else
659  #include
660  #endif
661 
662  6 -
663  in putget.m4 at line 24 added
664 
665  #ifdef _MSC_VER
666  #include
667  #endif // _MSC_VER ]
668 
669  Run
670  ./configure --prefix=/cygdrive/z/cwr/Software/Eclipse/CWRModelSource --
671  disable-examples --disable-cxx --disable-utilities
672 
673  Relevant environment variables
674  FC=ifort
675  F90=ifort
676  FFLAGS=/debug:full /traceback /nologo
677  FCFLAGS=/debug:full /traceback /nologo
678  FCFLAGS_f90=/debug:full /traceback /nologo
679  FLIBS=
680  CXX=
681  CPPFLAGS=/D AbsoftProFortran /D _MSC_VER /nologo
682 
683  IFORT_COMPILER10_POSIX=/cygdrive/c/Program Files/Intel/Compiler/
684  Fortran/10.1.013
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
688  TERM=cygwin
689  WINDIR=C:\WINDOWS
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
694  OS=CYGWIN
695  MAKEOVERRIDES=${-*-command-variables-*-}
696  USER=dallimor
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
705  MFLAGS=-w
706  VCINSTALLDIR_POSIX=/cygdrive/c/Program Files/Microsoft Visual Studio 8/
707  VC
708  PROCESSOR_LEVEL=6
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
728  CPU=i386
729  FP_NO_HOST_CHECK=NO
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
733  Files
734  MAKE_MODE=unix
735  INFOPATH=/usr/local/info:/usr/share/info:/usr/info:
736  PROGRAMFILES=C:\Program Files
737  CC=cl
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
744 
745 
746  Now configure works
747 
748  make will compile but fails on linking
749 
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
767  directory
768 
769  It looks like the Microsoft LInker doesn't like the GNU lib format.
770 
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
773  environment.
774 
775 ### ncdump bug for filenames beginning with a numeric character
776 
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:
779 
780  ncdump: name begins with space or control-character: 2
781 
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
785 
786  if((*cp >= 0x01 && *cp <= 0x32) || (*cp == 0x7f))
787 
788 with the following line instead
789 
790  if((*cp >= 0x00 && *cp <= 0x20) || (*cp == 0x7f))
791 
792 ------------------------------------------------------------------------
793 
794 Known Problems with netCDF 3.6.3
795 --------------------------------
796 
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)
805 
806 ------------------------------------------------------------------------
807 
808 ### Can't build shared library with F90 API on IRIX
809 
810 When building shared libraries on out IRIX test system, I got the
811 following error:
812 
813  ld32: FATAL 12 : Expecting n32 objects: /lib/libc.so.1 is o32.
814 
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
818 other users.
819 
820 ------------------------------------------------------------------------
821 
822 Known Problems with netCDF 3.6.2
823 --------------------------------
824 
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
828  files](#cxx_64-bit)
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)
849 
850 ------------------------------------------------------------------------
851 
852 ### Setting ARFLAGS does not work
853 
854 Sometimes when building netCDF, flags to the ar utility need to be set.
855 Setting ARFLAGS does not work.
856 
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.)
861 
862 Try the build again, setting AR\_FLAGS instead of ARFLAGS.
863 
864 ### Bugs in support for variables larger than 4 GiB
865 
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
871 data.
872 
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.
876 
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
881 
882  Assertion failed: remaining > 0, file putget.c, line 347
883 
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
887  occurs
888 
889  Arithmetic Exception(coredump)
890 
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
895 
896  Assertion failed: *ulp <= X_SIZE_MAX, file ncx.c, line 1810
897 
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
901 
902  Assertion failed: *ulp <= X_SIZE_MAX, file ncx.c, line 1810
903 
904 ### Bug in C++ interface prevents creating 64-bit offset format files
905 
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
910 rebuild:
911 
912  378c378
913  < mode = NC_WRITE;
914  ---
915  > mode |= NC_WRITE;
916  393c393
917  < mode = NC_NOCLOBBER;
918  ---
919  > mode |= NC_NOCLOBBER;
920 
921 This fix has been incorporated into netCDF 3.6.3 and later versions.
922 
923 ### The tests in nf\_test fail with seg fault with the Absoft Version 10.0 fortran compiler.
924 
925 The absoft fortran compiler, version 10.0, changes the way that a C
926 function returning string is called from fortran.
927 
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
930 nf\_test/nf\_test.
931 
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
934 set.
935 
936 Get the snapshot, and see the working output, on the [netCDF-3
937 snapshot](http://www.unidata.ucar.edu/software/netcdf/builds/snapshot/)
938 page.
939 
940 ### Shared libraries do not work with the NAG fortran compiler.
941 
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.
946 
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.
950 
951 Interested users may also wish to subscribe to the [netcdf-porting
952 mailing
953 list](http://www.unidata.ucar.edu/mailing_lists/archives/netcdf-porting/).
954 
955 ### The documented --enable-64bit option doesn't work.
956 
957 The --enable-64bit option appeared in the 3.6.1 release, and was--
958 removed for the 3.6.2 release.
959 
960 Unfortunately, the documentation was not updated, so that the 3.6.2
961 documentation still mentions the enable-64bit option. Sorry about that.
962 
963 The documentation has been corrected for the [netCDF-3
964 snapshot](http://www.unidata.ucar.edu/software/netcdf/builds/snapshot/)
965 and the [netCDF-4
966 snapshot](http://www.unidata.ucar.edu/software/netcdf/builds/snapshot/index_4.html)
967 documentation.
968 
969 ### Building netCDF-3.6.2 with gfortran version 4.2.x or 4.3.x fails.
970 
971 Something changed in gfortran version 4.3 relating to how fortran
972 functions can call C functions.
973 
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.
977 
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.
981 
982 The 3.6.2 build uses "gFortran", unless you specifically set the
983 CPPFLAGS environmental variable to "-DpgiFortran".
984 
985 This works in my bash shell:
986 
987  FC=gfortran CPPFLAGS=-DpgiFortran ./configure && make check
988 
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.
992 
993 ### Building shared libraries on Macintosh with g95 fails.
994 
995 Building shared libraries on the Macintosh fails
996 
997 
998  *** Testing netCDF-3 Fortran 90 API.
999  dyld: lazy symbol binding failed: Symbol not found: __g95_size
1000  Referenced from:
1001  /tmp/n3_mort/netcdf-3.6.2-snapshot2007052501/fortran/.libs/libnetcdff.4.dylib
1002  Expected in: flat namespace
1003 
1004  dyld: Symbol not found: __g95_size
1005  Referenced from:
1006  /tmp/n3_mort/netcdf-3.6.2-snapshot2007052501/fortran/.libs/libnetcdff.4.dylib
1007  Expected in: flat namespace
1008 
1009  FAIL: tst_f90
1010  =========================================
1011  1 of 5 tests failed
1012  Please report to support@unidata.ucar.edu
1013  =========================================
1014 
1015 ### Building shared libraries on HPUX with native tools results in only static libraries.
1016 
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.
1019 
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
1024 
1025 ### Building shared libraries on AIX fails.
1026 
1027 On the Unidata AIX platforms, the shared netCDF build fails with either
1028 the Fortran or C++ compilers, like this:
1029 
1030  make check-TESTS
1031  *** Creating fills.nc.
1032  *** SUCCESS!
1033  PASS: create_fills.sh
1034  /bin/sh: 16012 Segmentation fault(coredump)
1035  FAIL: nf_test
1036  /bin/sh: 16018 Segmentation fault(coredump)
1037  FAIL: tst_f77_v2
1038  /bin/sh: 16024 Segmentation fault(coredump)
1039  FAIL: ftest
1040  =========================================
1041  3 of 4 tests failed
1042  Please report to support@unidata.ucar.edu
1043  =========================================
1044 
1045 If built without fortran or C++, the build succeeds, but shared
1046 libraries are not built. (Static libraries are).
1047 
1048 I don't know what is causing this. If any AIX users can shed any light,
1049 that would be most helpful.
1050 
1051 Shared builds also fail the same way when using GNU compilers.
1052 
1053 ### Building with older versions of g++ fails.
1054 
1055 The build fails like this:
1056 
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,
1064  from netcdf.cpp:13:
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)':
1071 
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.
1075 
1076 ### The .NET build files are not included in the 3.6.2 release.
1077 
1078 The netCDF 3.6.2 release does not contain the .NET build files. Whoops!
1079 Sorry about that.
1080 
1081 .NET users should use the latest snapshot, or continue to use the 3.6.1
1082 release.
1083 
1084 This is now fixed in the netCDF-3 snapshot. Get the snapshot from the
1085 [netCDF-3 snapshot build page](../builds/snapshot).
1086 
1087 ### Snapshot .NET build files do not work for Visual Studio 8.0 beta.
1088 
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.
1091 
1092 Interested users may also wish to subscribe to the [netcdf-porting
1093 mailing
1094 list](http://www.unidata.ucar.edu/mailing_lists/archives/netcdf-porting/).
1095 
1096 ### The -disable-v2 option causes the fortran build to fail with some fortran compilers.
1097 
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.
1102 
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
1106 these).
1107 
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).
1111 
1112 This is fixed for future releases of netCDF.
1113 
1114 ### The --disable-c option does not work.
1115 
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.
1120 
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
1123 netCDF.
1124 
1125 Known Problems with netCDF 3.6.1
1126 --------------------------------
1127 
1128 [Building on IBM Bluegene login node (SUSE Linux)](#login_node_3_6_1)
1129 
1130 [Linux x86 Fedora4 with Intel ifort 9.0 compiler](#ifort_3_6_1)
1131 
1132 ### Building on IBM Bluegene login node (SUSE Linux)
1133 
1134 Michael McCracken reports the following:
1135 
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.
1139 
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).
1144 
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
1147  at SDSC haven't.
1148 
1149  Here's how I did it:
1150 
1151  After some debugging, I can configure and compile with the following
1152  commands.
1153 
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.
1157 
1158  setenv CC "xlc"
1159  setenv CFLAGS "-O3 -qstrict -DIBMR2Fortran"
1160  setenv CPP "xlc -E"
1161  setenv CXX "xlC"
1162  setenv CXXFLAGS "-O3 -qstrict"
1163  setenv CXXCPP "xlC -E"
1164  setenv F77 "xlf"
1165  setenv FC "xlf"
1166  setenv F90 "xlf90"
1167  setenv FFLAGS "-O3 -qstrict"
1168 
1169  ./configure --disable-flag-setting
1170 
1171  I get a clean build, and ncdump works for me...
1172 
1173 ### Linux x86 Fedora4 with Intel ifort 9.0 compiler
1174 
1175 For netCDF version 3.6.1, Jonathan Rougier contributes the following
1176 work around for an intel fortran compiler bug.
1177 
1178 There is a bug (which may have been fixed: see the ifort pages), which
1179 generates an error message along the lines of:
1180 
1181  IPO link: can not find "("
1182  ifort: error: problem during multi-file optimization compilation (code
1183  1)
1184 
1185 The documented cludge, which worked for me, is:
1186 
1187  # normal flags
1188 
1189  setenv FC ifort
1190  setenv FFLAGS "-mp -recursive"
1191  setenv CPPFLAGS "-DNDEBUG -DpgiFortran"
1192 
1193  # cludge
1194 
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
1198 
1199 which creates files called '(' and AS\_NEEDED in the appropriate places.
1200 
1201 ------------------------------------------------------------------------
1202 
1203 \
1204 
1205 Known Problems with netCDF 3.6.0
1206 --------------------------------
1207 
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
1215  AIX](#aix-config)
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
1223  data](#zeroedge)
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)
1227 
1228 ------------------------------------------------------------------------
1229 
1230 ### nctest fails on IRIX platform
1231 
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).
1234 
1235 The nctest fails when comparing the test-generated out with a saved copy
1236 of the output.
1237 
1238 This problem was fixed in the 3.6.1 release.
1239 
1240 ### C++ API doesn't build on Irix
1241 
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.
1244 
1245 ### Potentially serious bug with 64-bit offset files
1246 
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 (&gt; 2 GiB)
1256 netCDF files that use the new 64-bit offset format under the conditions
1257 described below.
1258 
1259 The bug occurs following this sequence of steps:
1260 
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.
1263 
1264 Later the file is opened for writing, followed by either of the
1265 following operations:
1266 
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).
1272 
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 (&gt; 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.
1290 
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
1294 64-bit offset
1295 format?](/software/netcdf/faq.html#Large%20File%20Support5).
1296 
1297 ### Cygwin Build Doesn't Work
1298 
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).
1301 
1302 ### Windows DLL doesn't include F77 API
1303 
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).
1308 
1309 ### F90 tests fail with Portland F90 compiler
1310 
1311 On some versions of the Portland Group F90 compiler, the F90 tests fail,
1312 looking something like this:
1313 
1314 
1315  *** Failure ***
1316  *** example_good.cdl 2000-04-05 21:33:14.000000000 +0200
1317  --- example.cdl 2005-01-11 10:21:31.624884000 +0100
1318  ***************
1319  *** 34,43 ****
1320  953, 954, 955,
1321  956, 957, 958,
1322  959, 960, 961,
1323  ! 962, 963, 964,
1324  ! 965, 966, 967,
1325  ! 968, 969, 970,
1326  ! 971, 972, 973 ;
1327 
1328  lat = -90, -87.5, -85, -82.5 ;
1329 
1330  --- 34,43 ----
1331  953, 954, 955,
1332  956, 957, 958,
1333  959, 960, 961,
1334  ! 950, 951, 952,
1335  ! 953, 954, 955,
1336  ! 956, 957, 958,
1337  ! 959, 960, 961 ;
1338 
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
1341 Group to fix this.
1342 
1343 ### Config doesn't find working F77 or F90 compiler on AIX
1344 
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.
1348 
1349 ### xlf90 fails to compile test program during configure on AIX
1350 
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.
1354 
1355 FIX: Make sure that -qsuffix=f=f90 is set in the F90FLAGS before running
1356 configure.
1357 
1358 This will be fixed in the next beta release.
1359 
1360 ### F90 functions not added to library on AIX
1361 
1362 On AIX systems, the F90 functions may not be added to the library. This
1363 is due to a quirk of AIX make.
1364 
1365 Before doing "make install", change to the Fortran90 directory (src/f90)
1366 and do "make". Then proceed to "make install".
1367 
1368 ### Problems with fortran compile because of -Df2cFortran being added by configure"
1369 
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.
1373 
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).
1376 
1377 ### Message: "ncgenyy.c is out-of-date with respect to ncgen.l"
1378 
1379 On some platforms (HP-UX 11.00, maybe others), make fails with an error
1380 message like:
1381 
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
1384 
1385 and then fails if the "flex" command is not found.
1386 
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:
1393 
1394  touch ncgen/ncgenyy.c
1395 
1396 Then rerun the make command.
1397 
1398 ### Configure help specifies FCFLAGS instead of FFLAGS
1399 
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.
1403 
1404 This problem will be is fixed in the next beta release. Until then, use
1405 FFLAGS, not FCFLAGS.
1406 
1407 ### Specifying a count length of zero returns an error instead of no data
1408 
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.
1418 
1419 This will be fixed in the next minor version.
1420 
1421 ### C++ library doesn't build under Cygwin
1422 
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
1425 built.
1426 
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).
1430 
1431 ### Large file problems in Visual C++ compile
1432 
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.
1436 
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.
1441 
1442 ### When using TEMP\_LARGE, need a trailing slash
1443 
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
1448 describes.
1449 
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.
1454 
1455 ------------------------------------------------------------------------
1456 
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).

Return to the Main Unidata NetCDF page.
Generated on Sat Apr 6 2019 08:19:00 for NetCDF. NetCDF is a Unidata library.