| • |
|
|
|
|||
|
||||
 |
Known Problems with NetCDF Distributions
This is where we document some reported problems releases of netCDF, and their workarounds. For more help see the build and test output for netCDF test plaforms, the list of other builds of netCDF, and the NetCDF Installation and Porting Guide. Get the current release of netCDF from the netCDF home page. |
The ncdump utility incorrectly assumes a default fill value of "255" for data of unsigned byte type, although no default fill value is assumed for data of type signed byte. There should be no default fill values when reading any byte type, signed or unsigned, because the byte ranges are too small to assume one of the values should appear as a missing value unless a _FillValue attribute is set explicitly. This bug is fixed in the current snapshot distribution.
Running the ncdump utility on a file with a compound type with an array field may result in a segmentation violation. A fix is in the current netCDF-4.0 snapshot distribution.
We believe there are some memory leaks associated with VLEN attributes in HDF5 1.8.1. This is being addressed by the HDF5 team, and will be fixed by the next HDF5 release.
On some Macintosh systems here at NetCDF World Test Center, on the hundreth floor of UCAR Tower #2, the following build error occurs:
*** Checking HDF5 enum types. *** Checking simple HDF5 enum type...ok. *** Checking HDF5 enum type missing values...ok. *** Tests successful! PASS: tst_h_enums dyld: Symbol not found: _H5P_CLS_FILE_ACCESS_g Referenced from: /tmp/n4_sid/netcdf-4.0-snapshot2008042320/libsrc4/.libs/libnetcdf.5.dylib Expected in: flat namespace FAIL: tst_lists dyld: Symbol not found: _H5P_CLS_FILE_ACCESS_g Referenced from: /tmp/n4_sid/netcdf-4.0-snapshot2008042320/libsrc4/.libs/libnetcdf.5.dylib Expected in: flat namespace FAIL: tst_dims dyld: Symbol not found: _H5P_CLS_FILE_ACCESS_g Referenced from: /tmp/n4_sid/netcdf-4.0-snapshot2008042320/libsrc4/.libs/libnetcdf.5.dylib Expected in: flat namespace etc.
This is caused by the -O2 parameter in the build. Set CFLAGS to -g and try again.
When building shared libraries on out IRIX test system, I got the following error:
ld32: FATAL 12 : Expecting n32 objects: /lib/libc.so.1 is o32.
Obviously there is some ABI confusion here, but we don't know how to resolve it. Any user who can solve this should email support-netcdf@unidata.ucar.edu so that we can share the method with other users.
Sometimes when building netCDF, flags to the ar utility need to be set. Setting ARFLAGS does not work.
(Note: If you are doing this to build 64-bit libraries on an AIX platform, the most fool-proof way to built 64-bit applications under AIX is to set the OBJECT_MODE environment variable to 64. If you still feel you must setr flags for ar, read on.)
Try the build again, setting AR_FLAGS instead of ARFLAGS.
As first reported by Mario Emmenlauer, there is a bug in netCDF-3.6.2 (and earlier versions) in the code for creating byte and short type variables greater than 4 GiB in size. This problem resulted in an assertion violation or arithmetic exception that would have caused a program to halt, rather than writing bad data or corrupting existing data.
A fix is available as a patch to the file libsrc/var.c in the netcdf-3.6.2 distribution. The bug is also fixed in the latest netCDF-3 snapshot release.
Assertion failed: remaining > 0, file putget.c, line 347
Arithmetic Exception(coredump)
Assertion failed: *ulp <= X_SIZE_MAX, file ncx.c, line 1810
Assertion failed: *ulp <= X_SIZE_MAX, file ncx.c, line 1810
As reported by Jos Verdoold, a bug in the netCDF 3.6.2 (and earlier versions) C++ interface prevents creating new files in Offset64Bits mode using the C++ API. The fix is to change two lines (378 and 393) in the file src/cxx/netcdf.cpp, changing "=" to "|=" in each line, then rebuild:
378c378 < mode = NC_WRITE; --- > mode |= NC_WRITE; 393c393 < mode = NC_NOCLOBBER; --- > mode |= NC_NOCLOBBER;
This fix has been incorporated into the next version and into the current snapshot.
The absoft fortran compiler, version 10.0, changes the way that a C function returning string is called from fortran.
This causes the absoft fortran settings in cfortran.h to no longer work, and this is reflected in a segmentation fault in the test program nf_test/nf_test.
As a workaround, users with absoft version 10 can get the latest netCDF-3 snapshot and build it with the --enable-absoft10-hack option set.
Get the snapshot, and see the working output, on the netCDF-3 snapshot page.
We have reports that the shared library build does not work with the NAG fortran compiler. The NAG compiler is not one of the compilers we current support (and test on) at Unidata. The only known work around is to build without the --enable-shared option.
Any user who can debug this problem with the NAG compiler should send the resuts to support-netcdf@unidata.ucar.edu, so that it can be incorporated into the netCDF distribution.
Interested users may also wish to subscribe to the netcdf-porting mailing list.
The --enable-64bit option appeared in the 3.6.1 release, and was-- removed for the 3.6.2 release.
Unfortunately, the documentation was not updated, so that the 3.6.2 documentation still mentions the enable-64bit option. Sorry about that.
The documentation has been corrected for the netCDF-3 snapshot and the netCDF-4 snapshot documentation.
Something changed in gfortran version 4.3 relating to how fortran functions can call C functions.
In netCDF, the interface between C and Fortran is handled by the cfortran.h package, which requires a pre-processor define describing the type of fortran you are using.
For gfortran up to version 4.1.x, the netCDF distribution builds cleanly with the "gFortran" preprocessor symbol set. For gfortran 4.2.x and greater, the "pgiFortran" preprocessor symbol works.
The 3.6.2 build uses "gFortran", unless you specifically set the CPPFLAGS environmental variable to "-DpgiFortran".
This works in my bash shell:
FC=gfortran CPPFLAGS=-DpgiFortran ./configure && make check
This problem has been fixed in the netCDF-3 snapshot. Now configure checks the version of gfortran before setting the appropriate flag.
Building shared libraries on the Macintosh fails
*** Testing netCDF-3 Fortran 90 API. dyld: lazy symbol binding failed: Symbol not found: __g95_size Referenced from: /tmp/n3_mort/netcdf-3.6.2-snapshot2007052501/fortran/.libs/libnetcdff.4.dylib Expected in: flat namespace dyld: Symbol not found: __g95_size Referenced from: /tmp/n3_mort/netcdf-3.6.2-snapshot2007052501/fortran/.libs/libnetcdff.4.dylib Expected in: flat namespace FAIL: tst_f90 ========================================= 1 of 5 tests failed Please report to support@unidata.ucar.edu =========================================
On the only HPUX machine I have access to for testing, the --enable-shared still results in only the static library being linked.
This may be because of and old C++ compiler on this particular platform. Any HPUX use who can provide information about this should send email to support-netcdf@unidata.ucar.edu. bash-2.04$ uname -a HP-UX tweety B.11.00 A 9000/785 2004553471
On the Unidata AIX platforms, the shared netCDF build fails with either the Fortran or C++ compilers, like this:
make check-TESTS *** Creating fills.nc. *** SUCCESS! PASS: create_fills.sh /bin/sh: 16012 Segmentation fault(coredump) FAIL: nf_test /bin/sh: 16018 Segmentation fault(coredump) FAIL: tst_f77_v2 /bin/sh: 16024 Segmentation fault(coredump) FAIL: ftest ========================================= 3 of 4 tests failed Please report to support@unidata.ucar.edu =========================================
If built without fortran or C++, the build succeeds, but shared libraries are not built. (Static libraries are).
I don't know what is causing this. If any AIX users can shed any light, that would be most helpful.
Shared builds also fail the same way when using GNU compilers.
The build fails like this:
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../fortran -DDEBUG -I../libsrc -g -O2 -MT netcdf.lo -MD -MP -MF .deps/netcdf.Tpo -c netcdf.cpp -o netcdf.o
In file included from /opt/gnu/gcc/include/c++/3.2/powerpc-ibm-aix5.0.0.0/bits/c++io.h:35,
from /opt/gnu/gcc/include/c++/3.2/bits/fpos.h:44,
from /opt/gnu/gcc/include/c++/3.2/iosfwd:46,
from /opt/gnu/gcc/include/c++/3.2/ios:44,
from /opt/gnu/gcc/include/c++/3.2/ostream:45,
from /opt/gnu/gcc/include/c++/3.2/iostream:45,
from netcdf.cpp:13:
/opt/gnu/gcc/include/c++/3.2/cstdio:108: `fgetpos' not declared
/opt/gnu/gcc/include/c++/3.2/cstdio:110: `fopen' not declared
/opt/gnu/gcc/include/c++/3.2/cstdio:115: `freopen' not declared
/opt/gnu/gcc/include/c++/3.2/cstdio:118: `fsetpos' not declared
netcdf.cpp: In member function `NcBool NcVar::set_cur(long int, long int, long
int, long int, long int)':
This happens in old versions of g++ when large files are used. To fix this, either upgrade your g++ compiler, or else use --disable-largefile with configure, to turn off large file handling.
The netCDF 3.6.2 release does not contain the .NET build files. Whoops! Sorry about that.
.NET users should use the latest snapshot, or continue to use the 3.6.1 release.
This is now fixed in the netCDF-3 snapshot. Get the snapshot from the netCDF-3 snapshot build page.
A user has reported that Visual Studio .NET version 8.0 beta does not build with the netCDF .NET build files in win32/NET.
Interested users may also wish to subscribe to the netcdf-porting mailing list.
The netCDF version 2 API is maintained for backward compatibility. We are committed to maintaining the V2 API for all future releases of netCDF. However, the --disable-v2 option is provided -- for users who wish to compile the netCDF libraries without the V2 API.
The --disable-v2 option will cause the fortran build to fail on some fortran 95 compilers because the netcdf.inc file still includes the names of the V2 API functions. (Other fortran 90 compilers ignore these).
If your compiler fails with --disable-v2, you can either refrain from using this option (that is, build the v2 API as well as the V3 API), or you can get the netCDF-3 snapshot.
This is fixed for future releases of netCDF.
The --disable-c option should turn off the building of the netCDF C library for use with --enable-separate-fortran (to save a small amount of tme building and testing. However this does not happen. The C library is built in any case.
Users may ignore this option in version 3.6.2. It is fixed in the netCDF-3 snapshot and for future releases of netCDF.
Michael McCracken reports the following:
Hi, I have been working with netcdf and parallel netcdf on bluegene at SDSC. I have no problems building a version to link with WRF and run on the ppc32 compute nodes. When I need to inspect a data file, I can't run the ncdump that is built with the cross-compiling configure without running it on a compute node. It works, but I end up waiting in the queue (and being charged for using 64 CPUs). I'd like to build an ncdump that works on the login node, and I was wondering if anyone had done that on a bluegene yet. The local staff at SDSC haven't. Here's how I did it: After some debugging, I can configure and compile with the following commands. I added -DIBMR2Fortran because apparently that's not getting set on bluegene (probably because it's linux and not AIX), and without it compiling in the fortran/ subdir barfs. setenv CC "xlc" setenv CFLAGS "-O3 -qstrict -DIBMR2Fortran" setenv CPP "xlc -E" setenv CXX "xlC" setenv CXXFLAGS "-O3 -qstrict" setenv CXXCPP "xlC -E" setenv F77 "xlf" setenv FC "xlf" setenv F90 "xlf90" setenv FFLAGS "-O3 -qstrict" ./configure --disable-flag-setting I get a clean build, and ncdump works for me...
For netCDF version 3.6.1, Jonathan Rougier contributes the following work around for an intel fortran compiler bug.
There is a bug (which may have been fixed: see the ifort pages), which generates an error message along the lines of:
IPO link: can not find "("
ifort: error: problem during multi-file optimization compilation (code
1)
The documented cludge, which worked for me, is:
# normal flags setenv FC ifort setenv FFLAGS "-mp -recursive" setenv CPPFLAGS "-DNDEBUG -DpgiFortran" # cludge echo null > \(; echo null > AS_NEEDED echo null > nf_test/\(; echo null > nf_test/AS_NEEDED echo null > ncgen/\(; echo null > ncgen/AS_NEEDED
which creates files called '(' and AS_NEEDED in the appropriate places.
It has been reported (by Atro Tossavainen) that nctest fails on some Irix builds. (We cannot duplicate this problem at netCDF World HQ).
The nctest fails when comparing the test-generated out with a saved copy of the output.
This problem was fixed in the 3.6.1 release.
On Irix systems without a recent version of the C++ compiler, the C++ API won't build. The solution is to set CXXFLAGS to -LANG:std.
Kevin Thomas of the University of Oklahoma has reported a potentially serious bug in using the new large file support in netCDF 3.6.0. Users of the new large file facilities are cautioned to either apply this one-line patch to netCDF 3.6.0 or to upgrade from version 3.6.0 to the current release version 3.6.0-p1, available from netcdf.tar.Z or netcdf.tar.gz. Until you can upgrade, avoid rewriting in place any large (> 2 GiB) netCDF files that use the new 64-bit offset format under the conditions described below.
The bug occurs following this sequence of steps:
Under these conditions, after you leave define mode or close the file, the file header is written out in the "classic" (version 1) netCDF format, chopping the leading bits off any variable offsets that were large enough to require more than 32 bits. If there were no such huge variable offsets, the file is undamaged and remains readable as a classic netCDF file. If there were any huge variable offsets (> 2 GiB), data for the first such variable and all subsequent variables will not be accessed correctly. It is possible to restore the header for such a file to the correct 64-bit offset form so that the data can subsequently be accessed correctly, if no data values have been overwritten since the file header was changed to classic format. Feel free to contact us for help restoring the file headers if this applies to you. If you have any large 64-bit offset format netCDF files that might have mistakenly been rewritten with classic format headers, please be careful not to write any more data into them, as it could overwrite data that could not subsequently be recovered.
If you want to know how to tell if a 64-bit offset file has been converted by this bug into a classic format file, see the answer to the FAQ How can I tell if a netCDF file uses the classic format or new 64-bit offset format?.
To build on Cygwin, you must get the latest 3.6.1 beta release.
The netCDF windows DLL doesn't include the Fortran API. We are working on this problem for the next release. Meanwhile, if you need the fortran API in your DLL, you'll have to use the netCDF 3.5.1 DLL.
On some versions of the Portland Group F90 compiler, the F90 tests fail, looking something like this:
*** Failure ***
*** example_good.cdl 2000-04-05 21:33:14.000000000 +0200
--- example.cdl 2005-01-11 10:21:31.624884000 +0100
***************
*** 34,43 ****
953, 954, 955,
956, 957, 958,
959, 960, 961,
! 962, 963, 964,
! 965, 966, 967,
! 968, 969, 970,
! 971, 972, 973 ;
lat = -90, -87.5, -85, -82.5 ;
--- 34,43 ----
953, 954, 955,
956, 957, 958,
959, 960, 961,
! 950, 951, 952,
! 953, 954, 955,
! 956, 957, 958,
! 959, 960, 961 ;
This problem is caused by a bug in the Portland F90 compiler. Upgrade to the latest version of the compiler or get the free patch from Portland Group to fix this.
On AIX systems, the configure step can't find either the F90 or the F77 compiler. On AIX system, you must set the environment variables FC and F90 to xlf and xlf95.
On AIX systems, the F90 option -qsuffix=f=f90 is required in F90FLAGS. Configure should automatically detect and add this to F90FLAGS if it's not already there, but it doesn't.
FIX: Make sure that -qsuffix=f=f90 is set in the F90FLAGS before running configure.
This will be fixed in the next beta release.
On AIX systems, the F90 functions may not be added to the library. This is due to a quirk of AIX make.
Before doing "make install", change to the Fortran90 directory (src/f90) and do "make". Then proceed to "make install".
With some fortran compilers, such as Absoft, the configure script stupidly adds a -Df2cFortran to the C preprocessor flags, which causes the fortran tests in nf_test to fail to link.
This problem is fixed in the 3.6.1 beta release. Get the 3.6.1 beta release.
On some platforms (HP-UX 11.00, maybe others), make fails with an error message like:
Warning: ncgenyy.c is out-of-date with respect to ncgen.l Warning: It should be recreated via flex on a SunOS 5 systemand then fails if the "flex" command is not found.
The problem is that the modification time on the source file src/ncgen/ncgenyy.c is being interpreted as earlier than the modification time on the source file src/ncgen/ncgen.l, even though ncgenyy.c was actually created after ncgen.l was modified. To workaround this problem on a Unix system, run the following command from the netCDF src/ directory to update the modification time of the derived file:
touch ncgen/ncgenyy.cThen rerun the make command.
If you run "configure --help", it suggests setting "FCFLAGS" for the fortran compiler flags, but "FFLAGS" is actually used for the Fortran compiler flags. "FCFLAGS" is ignored when compiling.
This problem will be is fixed in the next beta release. Until then, use FFLAGS, not FCFLAGS.
For access to array sections, strided access, or mapped access, you need to specify both a start index vector and a count vector, where the count vector specifies the number of slices along each edge to access. If the start index vector specifies the maximum dimension size and the corresponding count vector is zero, the library should just return no data, but instead it returns an error status indicating "Index exceeds dimension bound". This problem has been present in all versions of netCDF, and the test programs even verify that in this case an error is returned rather than gracefully accessing no data.
This will be fixed in the next minor version.
Running configure on Cygwin fails to find GNU C++ compiler, even if it is present on the platform. As a result, the C++ interface is never built.
This problem is fixed in the 3.6.1 beta release. Cygwin users interested in the C++ interface should get the 3.6.1 beta release.
The use of large files, and an 8-byte off_t type, is not handled correctly in the 3.6.0 release of the code and project files needed to compile the netCDF library with Visual C++.NET.
This problem is fixed in the 3.6.1 beta release. Users interested in building their own DLL should get the 3.6.1 beta release. The DLL offered on the binary release page is 3.6.1 beta.
When using the environment variable TEMP_LARGE during the netCDF 3.6.0 make extra_test phase, the directory name must be followed by a slash to work. For example, use 'setenv TEMP_LARGE /tmp/' instead of 'setenv TEMP_LARGE /tmp', as one would usually expect, and as the documentation describes.
This problem is fixed in the 3.6.1 beta release. Users of 3.6.0 should specify the trailing slash to use the TEMP_LARGE environment variable in make extra_test.
Reported problems and workarounds are also available for some previous releases: version 3.5, version 3.4, version 3.3.1, version 3.3, version 2.4.3, and version 2.4.2.
| Contact Us • Site Map • Search • Terms and Conditions • Privacy Policy • Participation Policy | ||||||
|
||||||
