Appendix B. Installing gdb
gdb comes with a configure script that automates the process
of preparing gdb for installation; you can then use make to
build the gdb program.
The gdb distribution includes all the source code you need for
gdb in a single directory, whose name is usually composed by
appending the version number to gdb.
For example, the gdb version 2003-07-22-cvs distribution is in the
gdb-2003-07-22-cvs directory. That directory contains:
- gdb-2003-07-22-cvs/configure (and supporting files)
script for configuring gdb and all its supporting libraries
- gdb-2003-07-22-cvs/gdb
the source specific to gdb itself
- gdb-2003-07-22-cvs/bfd
source for the Binary File Descriptor library
- gdb-2003-07-22-cvs/include
gnu include files
- gdb-2003-07-22-cvs/libiberty
source for the -liberty free software library
- gdb-2003-07-22-cvs/opcodes
source for the library of opcode tables and disassemblers
- gdb-2003-07-22-cvs/readline
source for the gnu command-line interface
- gdb-2003-07-22-cvs/glob
source for the gnu filename pattern-matching subroutine
- gdb-2003-07-22-cvs/mmalloc
source for the gnu memory-mapped malloc package
The simplest way to configure and build gdb is to run configure
from the gdb-version-number source directory, which in
this example is the gdb-2003-07-22-cvs directory.
First switch to the gdb-version-number source directory
if you are not already in it; then run configure. Pass the
identifier for the platform on which gdb will run as an
argument.
For example:
cd gdb-2003-07-22-cvs
./configure host
make |
where host is an identifier such as sun4 or
decstation, that identifies the platform where gdb will run.
(You can often leave off host; configure tries to guess the
correct value by examining your system.)
Running configure host and then running make builds the
bfd, readline, mmalloc, and libiberty
libraries, then gdb itself. The configured source files, and the
binaries, are left in the corresponding source directories.
configure is a Bourne-shell (/bin/sh) script; if your
system does not recognize this automatically when you run a different
shell, you may need to run sh on it explicitly:
If you run configure from a directory that contains source
directories for multiple libraries or programs, such as the
gdb-2003-07-22-cvs source directory for version 2003-07-22-cvs, configure
creates configuration files for every directory level underneath (unless
you tell it not to, with the -norecursion option).
You should run the configure script from the top directory in the
source tree, the gdb-version-number directory. If you run
configure from one of the subdirectories, you will configure only
that subdirectory. That is usually not what you want. In particular,
if you run the first configure from the gdb subdirectory
of the gdb-version-number directory, you will omit the
configuration of bfd, readline, and other sibling
directories of the gdb subdirectory. This leads to build errors
about missing include files such as bfd/bfd.h.
You can install gdb anywhere; it has no hardwired paths.
However, you should make sure that the shell on your path (named by
the SHELL environment variable) is publicly readable. Remember
that gdb uses the shell to start your program--some systems refuse to
let gdb debug child processes whose programs are not readable.
B.1. Compiling gdb in another directory
If you want to run gdb versions for several host or target machines,
you need a different gdb compiled for each combination of
host and target. configure is designed to make this easy by
allowing you to generate each configuration in a separate subdirectory,
rather than in the source directory. If your make program
handles the VPATH feature (gnu make does), running
make in each of these directories builds the gdb
program specified there.
To build gdb in a separate directory, run configure
with the -srcdir option to specify where to find the source.
(You also need to specify a path to find configure
itself from your working directory. If the path to configure
would be the same as the argument to -srcdir, you can leave out
the -srcdir option; it is assumed.)
For example, with version 2003-07-22-cvs, you can build gdb in a
separate directory for a Sun 4 like this:
cd gdb-2003-07-22-cvs
mkdir ../gdb-sun4
cd ../gdb-sun4
../gdb-2003-07-22-cvs/configure sun4
make
|
When configure builds a configuration using a remote source
directory, it creates a tree for the binaries with the same structure
(and using the same names) as the tree under the source directory. In
the example, you'd find the Sun 4 library libiberty.a in the
directory gdb-sun4/libiberty, and gdb itself in
gdb-sun4/gdb.
Make sure that your path to the configure script has just one
instance of gdb in it. If your path to configure looks
like ../gdb-2003-07-22-cvs/gdb/configure, you are configuring only
one subdirectory of gdb, not the whole package. This leads to
build errors about missing include files such as bfd/bfd.h.
One popular reason to build several gdb configurations in separate
directories is to configure gdb for cross-compiling (where
gdb runs on one machine--the host--while debugging
programs that run on another machine--the target).
You specify a cross-debugging target by
giving the -target=target option to configure.
When you run make to build a program or library, you must run
it in a configured directory--whatever directory you were in when you
called configure (or one of its subdirectories).
The Makefile that configure generates in each source
directory also runs recursively. If you type make in a source
directory such as gdb-2003-07-22-cvs (or in a separate configured
directory configured with -srcdir=dirname/gdb-2003-07-22-cvs), you
will build all the required libraries, and then build GDB.
When you have multiple hosts or targets configured in separate
directories, you can run make on them in parallel (for example,
if they are NFS-mounted on each of the hosts); they will not interfere
with each other.
