OPeNDAP

If your application accesses netCDF data through the standard netCDF library, it should be fairly straight forward to relink it with the OPeNDAP enabled netCDF library. First off, you will need some OPeNDAP libraries: the third-party-packages libraries; the OPeNDAP core (DAP) libraries; and the OPeNDAP netCDF library (see the Note below for some comments on library and compiler compatibilities). Second, you need to link your application with these libraries. This should involve adding several library flags to your normal compiling/linking commands. In particular:

• Instead of '-I/usr/local/netcdf/include' use the results of ncdap-config --cflags
• Instead of '-L/usr/local/netcdf/lib' and '-lnetcdf' use the results of ncdap-config --libs

For instance,

• OPeNDAP libnc-dap 3.7.4 release

   g++ -c -o sample.o `ncdap-config --cflags` sample.c 
   g++ -g -o sample sample.o `ncdap-config --libs` 	 

Note: We have found that using our pre-built binary versions of the libraries for relinking with your application can be problematic. The reason is that the compiler used to compile your application must match the compiler used to build the OPeNDAP libraries (often the version of compiler is important, too). For this reason, we generally suggest that you build the OPeNDAP libraries from source using the compiler you use to build your application.

We are using the GNU compilers (GCC 4.0.1 as of 22 Jul 2009). So, if you are using the same compiler and would like to try linking with our pre-built binaries, please let us know if you successfully link to our binary releases.

There are several possible ways to link your Fortran program with the DODS netCDF library. The libraries you must specify in the linking step depend on how you compile and link your program.

If linking with g++, you must specify '-lg2c' to make sure you link with the GNU Fortran libraries. For example,

 g77 -g -c `ncdap-config --fflags` sample.f 
 g++ -g -o sample sample.o `ncdap-config --flibs`

If you link with g77, use '-lstdc++' to include the C++ library. If you link with gcc, use '-lstdc++ -lg2c', to link with both the C++ and Fortran libraries. (You can compile your program with gcc, g++, or g77.)

If you are not using the GNU Fortran compiler, you will more than likely have to build the DODS netCDF library yourself. Also, if you link with g++, you will need to specify the libraries specific to your Fortran compiler. On the other hand, if you link with your Fortran compiler, you will need to specify the GNU C++ library, i.e., '-lstdc++'. To build the DODS netCDF library yourself, please take a look at the FAQ " How do I build the netCDF Fortran jackets?" and look for suggestions on building for your compiler (be sure to look in the non-DODS netCDF INSTALL file).

As you may have guessed, we stick with the GNU compilers when building our binary releases, generally from GCC 4.0.1 (as of 22 Jul 2009). Here are the environment variables we set:

• CC=gcc
• CXX=g++
• FC=gfortran
• FFLAGS=-g
• CPPFLAGS=-Df2cFortran

I believe our standard binary release should work for you if you are using g77, f2c, or fort77 (which uses f2c). This may work for other compilers as well. Please let us know if you successfully link to our binary releases with other compilers.

The main problem here is that, even though no Fortran is compiled while building the netCDF library, you must specify a working Fortran compiler to get the Fortran jackets. More to the point, you must specify the compiler that you will be using on your Fortran code. Since every Fortran compiler is different, the C code (the netCDF Fortran jackets) needs to be configured properly to allow communication with the Fortran code (your application).

So, this means that your netCDF library has to have been built with the same Fortran compiler you use to build your Fortran code. The DODS provided binary releases are built with the GNU compilers (gcc, g++, and g77), generally from GCC 2.95.2 (as of 11 Oct 2000). So if you are using a different Fortran compiler, you will need to build the DODS netCDF client library yourself.

As with the non-DODS netCDF package, you should "[s]et the environment variables CPPFLAGS, CC, CFLAGS, FC, FFLAGS, CXX, and CXXFLAGS (and perhaps LIBS) to represent [your] environment." The documentation (i.e., the INSTALL file) for the non-DODS netCDF package gives environment setups successfully used for a variety of platform/compiler combinations.

Below are the settings we have used with the DODS netCDF client library. If you need to build it for a different compiler, take a look at the INSTALL file mentioned above. If you have success with other Fortran compilers, please let us know so we can list it here.

• GNU Fortran
  • CC=gcc
  • CXX=g++
  • FC=gfortran
  • FFLAGS=-g
  • CPPFLAGS=-Df2cFortran
  Also good when using f2c (or fort77 on Linux).
• NAG f90
  • CC=gcc
  • CXX=g++
  • FC=f90
  • FFLAGS=-g
  • CPPFLAGS=-DNAGf90Fortran

Now for linking your Fortran code to these libraries, see our FAQ " How do I link my Fortran program to the DODS netCDF library? "

1. As is standard practice for OS/X, I replaced etc/config.guess and config.sub with /usr/libexec/config.guess and /usr/libexec/config.sub. This allows configure to correctly identify the platform as powerpc-apple-darwin5.5. I believe that the latest versions of autoconf come with config.guess/.sub files that handle OS/X properly so this should be easy to fix.
2. The gcc version test in the dap and nc3 configure scripts fails for Apple's modified gcc, because "gcc -v" gives the following output: Reading specs from /usr/libexec/gcc/darwin/ppc/2.95.2/specs Apple Computer, Inc. version gcc-934.3, based on gcc version 2.95.2 19991024 (release) The regexp gets stuck on the "." in "Inc.", and GCC_VER ends up set to: Apple Computer, I. version gcc-934.3, based on gcc version 2.95.2 19991024 (release) My quick fix for this was to comment out the error message in the case statement and instead set GCC_VER = `gcc --version`, which gives the following output: 2.95.2 I am not knowledgeable enough with autoconf to say how the test should be modified to be portable though..
3. I commented out the definition of HAVE_APPKIT_APPKIT_H in include/w3c-libwww/wwwconf.h. I have no idea why or what this is used for. I will investigate further if you don't know either.
4. I commented out line 974 of util.cc: xdf_destroy(xdr); The compiler was giving a "wrong number of arguments" error". I couldn't figure it out so I just commented out the line. I expect this introduced a memory leak so I we will have to figure out a better solution."
5. Since I was working with the 3.2.1 release and not the current SVN sources, I commented out various references to libdap++-gui in the dap and nc3/ncdump makefiles.
6. I had to run ranlib on lib/libwww.a. There was a file called "__.SYMDEF SORTED" which looks like it was supposed to be the symbol table for libwww sitting in the lib/ directory, so perhaps the ranlib command line didn't work quite right the first time. At this point libdap++.a and libnc-dods.a both built successfully.
7. The linker reported unresolved symbols for add_connect(NCConnect), del_connect(NCConnect), and a few other members of the Connections template. According to some messages on the web, there are template instantiation bugs in Apple's gcc, and the best fix they had found was to include the instantation as a separate object file. So I added "../inst.o" to the link line for dncdump and lo and behold, it worked.