When a user links an existing a program to the OPeNDAP libraries, there are several possible conditions that may cause problems.
If this is the case for a given program, there is generally no good solution beside rewriting the software to conform to a strict usage of the data reading parts of the given API. Of course if the problem is that the program uses more than one API, you can try linking the program with an OPeNDAP-compliant version of the second API as well.
The OPeNDAP libraries are large, and the g++, www,
expect, and tcl libraries on which they are built are even
larger. This means that the executable version of a re-linked OPeNDAP client can seem unreasonably obese. Much of the disk space is occupied
by symbol tables, which can be removed from the executable file with
the strip utility. In many cases, a user can recover a
substantial amount of disk space this way.
CAUTION: Without familiarity with the OPeNDAP software, it is best only to strip the executable files. Stripping object files or libraries might leave them in a useless condition for the linker. Furthermore, stripping an executable file removes symbol names, which may make diagnosing problems more difficult.
The OPeNDAP libraries only affect the data reading functionality
of the specified API. There are no OPeNDAP replacements for functions
like netCDF's ncputrec(), that write data to a disk file.
These functions are included in the OPeNDAP-compliant API library, but
they operate in a manner identical to the original (non-OPeNDAP)
versions, that is, they work on local files only, attempting to write
"over the network" will result in an error.