Updated for version 3.19.1 of the OPeNDAP DAP2/4 library software. Installing the DAP2/4 library --------------------------------------------------------------------------- BUILDING THE SOFTWARE REQUIREMENTS NOTES --------------------------------------------------------------------------- BUILDING THE SOFTWARE To build the OPeNDAP DAP2/4 library and the getdap client program, follow these steps: 0. Please skim REQUIREMENTS and NOTES sections of this file before reporting problems. Thanks. 1. Type `./configure' at the system prompt. On some systems you may have to type `sh configure'. For people building from git, see below. 2. Type `make' to build the library, `make check' to run the tests. You must have CppUnit to run `make check.' On a Mandrake/Mandriva system, you need to copy or link conf/config.guess into the 'tests' directory and then run the tests. 3. Type `make install' to install the library files. The libraries (libdap.a. libdapclient.a and libdapserver.a, etc.), their header files and the getdap and dap-config utilities install under /usr/local/ in lib, include/libdap and bin by default. Use the --prefix option to specify a different root directory. For example, './configure --prefix=/opt/opendap' would set the build so that the library was installed in /opt/opendap/lib, ... Building from Our GIT Repository A git clone of https://github.com/opendap/libdap4 will get you the newest code. You'll need the autotools toolchain. First, run autoreconf --force --install --verbose Then run ./configure, make and make check. Use --prefix with configure to set the installation to a location other than /usr/local. Use --enable-developer to turn on the library's asserts and build with debugging symbols. Use --jobs=N with make and make check to run those in parallel on multi core machines and add TESTSUITEFLAGS=-j9 to make check to run the regression tests in parallel. AFTER INSTALLING o Set the PATH environment variable to include the bin directory where libdap was installed. For example, if using the default installation directory, which is /usr/local, make sure that /usr/local/bin is on your path. This is important because often libdap is built so that some other software can then be built, but without setting PATH, those other packages might not detect the newly installed libdap. o Set the LD_LIBRARY_PATH environment variable to include the lib directory where libdap was installed. For example, if using the default installation directory, which is /usr/local, make sure that /usr/local/lib is part of LD_LIBRARY_PATH. If you have set $prefix so that the libraries are installed in a directory that's included in ld.so.conf (on linux; other systems may use a slightly different name) you don't have to use LD_LIBRARY_PATH but, but if you don't use LD_LIBRARY_PATH, **make sure to re-run ldconfig**. REQUIREMENTS o To build from a fresh git clone, you'll need automake 1.11, autoconf 2.63 and libtool 2.2.6. Earlier versions may work, but may cause problems, particularly with the 'distcheck' target for make. Given those requirements, use 'autoreconf --force --install --verbose' and then build as described above. You also need bison 3 and flex 2.5.35 or greater. o The library uses libcurl, libxml2 and libuuid (the latter on linux but not OSX). You will need these libraries installed on your system to successfully run configure and build the library. You must have libcurl version 7.19.0 or newer and libxml2 2.7.0 or newer. o If you are concerned about introducing problems with your OS's package system, build and install curl, etc., into a special directory (e.g., /opt/opendap/) and then be sure to set PATH to include the curl-config and xml2-config scripts before running configure (e.g., run configure as 'PATH="$PATH:/opt/opendap/bin';./configure'). You probably should install libdap.a under /opt/opendap as well, so set prefix to that path: 'PATH="$PATH:/opt/opendap/bin';./configure --prefix=/opt/opendap' o We build this using gcc 4.2.1 and clang 602.0.53 NOTES o Check for other INSTALL.* files to see if there's information specific to your OS (e.g., AIX). o If you are building on a new platform (one for which we don't supply binaries), please run the tests and tell us about any failures. To do a really complete job of this you'll need to get the GNU test system called DejaGNU and the CppUnit unit testing package. It is very simple to install these and we're very willing to help, so don't be shy! o If you are developing code that uses the DAP, get autoconf and subversion (SVN). We maintain a SVN-managed source tree that people outside the group may access. See http://scm.opendap.org/trac/ o The gnulib software is used to provide replacement functions when autoconf detects that is necessary. To update the gnulib, check it out from CVS and run '$gnulib_home/gnulib-tool --lgpl --import' in this directory. Macros in configure.ac supply gnulib-tool with all the information it needs. Only developers working on libdap should ever have to do this. o To build a rpm file for a source or binary distribution use 'make rpm' or 'make srpm'. These targets should run 'make dist' to build the required tar.gz file first. You may need root privileges for these targets to work. o To build a Mac OS/X package, use the 'pkg' target. Read over the target to get a feel for how it works. You will need PackageMaker, which should already be installed on your system, and you will need DropDMG, which can be obtained at http://c-command.com/dropdmg/. The target has been automated to generate a ReadMe.txt file, update the Info.plist file, run PackageMaker and DropDMG. o DEBUGGING AIDS - The DAP API includes the following debugging aids that may be of help to you in developing new OPeNDAP applications. - DBG: simple program instrumentation -- see the file debug.h. - DBG2: more elaborate program instrumentation -- by convention this is used for output that is half a page or more, while DEBUG is used for single line output. - In the past we used efence and dbnew to help debug dynamic memory programming errors. We are now using valgrind and suggest you do the same. On some Linux platforms you should export MALLOC_CHECK_=0 in the shell before running valgrind. This is true for the unit tests and may be true for other code. You'll also notice that the Makefile contains CXX and C compile-time flags for debugging. These will greatly simplify using valgrind and/or a debugger. To use these, don't hack up the Makefile.am. Instead export CXXFLAGS with the values you want and then run configure. For example: export CXXFLAGS="-g3 -O0 -Wall -fno-defer-pop"; ./configure - To build with program instrumentation use `--enable-debug=<level>' where <level> is 1 or 2.