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.