Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Mail Systems
Eclipse Documentation

How To Guides
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Problem Solutions
Privacy Policy




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


the source specific to gdb itself


source for the Binary File Descriptor library


gnu include files


source for the -liberty free software library


source for the library of opcode tables and disassemblers


source for the gnu command-line interface


source for the gnu filename pattern-matching subroutine


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

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:

sh configure host

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

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.

  Published under the terms of the GNU General Public License Design by Interspire