If the ./configure; make check fails, it's a good idea to turn off the C++ and Fortran interfaces, and try to build the C interface alone. All other interfaces depend on the C interface, so nothing else will work until the C interface works. To turn off C++ and Fortran, set environment variables CXX and FC to NULL before running the netCDF configure script (with csh: setenv FC ”;setenv CXX ”).
Turning off the Fortran and C++ interfaces results in a much shorter build and test cycle, which is useful for debugging problems.
If the netCDF configure fails, most likely the problem is with your development environment. The configure script looks through your path to find all the tools it needs to build netCDF, including C compiler and linker, the ar, ranlib, and others. The configure script will tell you what tools it found, and where they are on your system. Here's part of configure's output on a Linux machine:
checking CPPFLAGS... checking CC CFLAGS... cc -g -O2 checking type cc... cc is /usr/bin/cc checking CXX... c++ checking CXXFLAGS... -g -O2 checking type c++... c++ is /usr/bin/c++ checking FC... gfortran checking FFLAGS... -g -O2 checking type gfortran... gfortran is /usr/bin/gfortran checking F90... gfortran checking FCFLAGS... -g -O2 checking type gfortran... gfortran is /usr/bin/gfortran checking AR... ar checking AR_FLAGS... cru checking type ar... ar is /usr/bin/ar checking NM... /usr/bin/nm -B checking NMFLAGS... checking for /usr/bin/nm... /usr/bin/nm -B checking nm flags...
Make sure that the tools, directories, and flags are set to reasonable values, and compatible tools. For example the GNU tools may not inter-operate well with vendor tools. If you're using a vendor compiler, you may need to use the ar, nm, and ranlib that the vendor supplied.
As configure runs, it creates a config.log file. If configure crashes, do a text search of config.log for thing it was checking before crashing. If you have a licensing or tool compatibility problem, it will be obvious in config.log.
If the configure script runs, but the compile step doesn't work, or the tests don't complete successfully, the problem is probably in your CFLAGS or CPPFLAGS.
Frequently shared libraries are a rich source of problems. If your build is not working, and you are using the –enable-shared option to generate shared libraries, then try to build without –enable-shared, and see if the static library build works.
If you are planning on using large files (i.e. > 2 GiB), then you may wish to rerun configure with –enable-large-file-tests to ensure that large files work on your system.
Some DAP tests (in the directory ncdap_test) attempt to access an external server at opendap.org. It is possible that the DAP server may not be running at test time, or the network access may be faulty or that the output of the test server has changed. In this case, the DAP tests may fail. Because of this, the use of these tests is controlled by the –enable-dap-remote-tests option.