diff options
| author | mrg <mrg@NetBSD.org> | 2004-12-08 09:47:04 +0000 |
|---|---|---|
| committer | mrg <mrg@NetBSD.org> | 2004-12-08 09:47:04 +0000 |
| commit | 0b0695816fdee18c0c19132cc7d96dfbe4e06206 (patch) | |
| tree | 843c7f91830c678cbf4b4677f638c350b731248c /gnu | |
| parent | ddc1ca5b37d2a6347c7b7ef5c77209af95ea4c06 (diff) | |
these files are created at build time
Diffstat (limited to 'gnu')
| -rw-r--r-- | gnu/dist/binutils/etc/configure.info | 2781 | ||||
| -rw-r--r-- | gnu/dist/binutils/etc/standards.info | 341 | ||||
| -rw-r--r-- | gnu/dist/binutils/gprof/gprof.info | 2314 |
3 files changed, 5164 insertions, 272 deletions
diff --git a/gnu/dist/binutils/etc/configure.info b/gnu/dist/binutils/etc/configure.info index 10490afc014..1f6bfc6acb2 100644 --- a/gnu/dist/binutils/etc/configure.info +++ b/gnu/dist/binutils/etc/configure.info @@ -1,4 +1,4 @@ -This is configure.info, produced by makeinfo version 4.3 from +This is configure.info, produced by makeinfo version 4.6 from ./configure.texi. INFO-DIR-SECTION GNU admin @@ -25,71 +25,2724 @@ versions, except that this permission notice may be stated in a translation approved by the Foundation. -Indirect: -configure.info-1: 971 -configure.info-2: 48782 -configure.info-3: 98073 +File: configure.info, Node: Top, Next: Introduction, Up: (dir) + +GNU configure and build system +****************************** + +The GNU configure and build system. + +* Menu: + +* Introduction:: Introduction. +* Getting Started:: Getting Started. +* Files:: Files. +* Configuration Names:: Configuration Names. +* Cross Compilation Tools:: Cross Compilation Tools. +* Canadian Cross:: Canadian Cross. +* Cygnus Configure:: Cygnus Configure. +* Multilibs:: Multilibs. +* FAQ:: Frequently Asked Questions. +* Index:: Index. + + +File: configure.info, Node: Introduction, Next: Getting Started, Prev: Top, Up: Top + +Introduction +************ + +This document describes the GNU configure and build systems. It +describes how autoconf, automake, libtool, and make fit together. It +also includes a discussion of the older Cygnus configure system. + + This document does not describe in detail how to use each of the +tools; see the respective manuals for that. Instead, it describes +which files the developer must write, which files are machine generated +and how they are generated, and where certain common problems should be +addressed. + + This document draws on several sources, including the autoconf +manual by David MacKenzie (*note autoconf overview: (autoconf)Top.), +the automake manual by David MacKenzie and Tom Tromey (*note automake +overview: (automake)Top.), the libtool manual by Gordon Matzigkeit +(*note libtool overview: (libtool)Top.), and the Cygnus configure +manual by K. Richard Pixley. + +* Menu: + +* Goals:: Goals. +* Tools:: The tools. +* History:: History. +* Building:: Building. + + +File: configure.info, Node: Goals, Next: Tools, Up: Introduction + +Goals +===== + +The GNU configure and build system has two main goals. + + The first is to simplify the development of portable programs. The +system permits the developer to concentrate on writing the program, +simplifying many details of portability across Unix and even Windows +systems, and permitting the developer to describe how to build the +program using simple rules rather than complex Makefiles. + + The second is to simplify the building of programs distributed as +source code. All programs are built using a simple, standardized, two +step process. The program builder need not install any special tools in +order to build the program. + + +File: configure.info, Node: Tools, Next: History, Prev: Goals, Up: Introduction + +Tools +===== + +The GNU configure and build system is comprised of several different +tools. Program developers must build and install all of these tools. + + People who just want to build programs from distributed sources +normally do not need any special tools beyond a Unix shell, a make +program, and a C compiler. + +autoconf + provides a general portability framework, based on testing the + features of the host system at build time. + +automake + a system for describing how to build a program, permitting the + developer to write a simplified `Makefile'. + +libtool + a standardized approach to building shared libraries. + +gettext + provides a framework for translation of text messages into other + languages; not really discussed in this document. + +m4 + autoconf requires the GNU version of m4; the standard Unix m4 does + not suffice. + +perl + automake requires perl. + + +File: configure.info, Node: History, Next: Building, Prev: Tools, Up: Introduction + +History +======= + +This is a very brief and probably inaccurate history. + + As the number of Unix variants increased during the 1980s, it became +harder to write programs which could run on all variants. While it was +often possible to use `#ifdef' to identify particular systems, +developers frequently did not have access to every system, and the +characteristics of some systems changed from version to version. + + By 1992, at least three different approaches had been developed: + * The Metaconfig program, by Larry Wall, Harlan Stenn, and Raphael + Manfredi. + + * The Cygnus configure script, by K. Richard Pixley, and the gcc + configure script, by Richard Stallman. These use essentially the + same approach, and the developers communicated regularly. + + * The autoconf program, by David MacKenzie. + + The Metaconfig program is still used for Perl and a few other +programs. It is part of the Dist package. I do not know if it is +being developed. + + In 1994, David MacKenzie and others modified autoconf to incorporate +all the features of Cygnus configure. Since then, there has been a +slow but steady conversion of GNU programs from Cygnus configure to +autoconf. gcc has been converted, eliminating the gcc configure script. + + GNU autoconf was regularly maintained until late 1996. As of this +writing in June, 1998, it has no public maintainer. + + Most programs are built using the make program, which requires the +developer to write Makefiles describing how to build the programs. +Since most programs are built in pretty much the same way, this led to a +lot of duplication. + + The X Window system is built using the imake tool, which uses a +database of rules to eliminate the duplication. However, building a +tool which was developed using imake requires that the builder have +imake installed, violating one of the goals of the GNU system. + + The new BSD make provides a standard library of Makefile fragments, +which permits developers to write very simple Makefiles. However, this +requires that the builder install the new BSD make program. + + In 1994, David MacKenzie wrote the first version of automake, which +permitted writing a simple build description which was converted into a +Makefile which could be used by the standard make program. In 1995, Tom +Tromey completely rewrote automake in Perl, and he continues to enhance +it. + + Various free packages built libraries, and by around 1995 several +included support to build shared libraries on various platforms. +However, there was no consistent approach. In early 1996, Gordon +Matzigkeit began working on libtool, which provided a standardized +approach to building shared libraries. This was integrated into +automake from the start. + + The development of automake and libtool was driven by the GNITS +project, a group of GNU maintainers who designed standardized tools to +help meet the GNU coding standards. + + +File: configure.info, Node: Building, Prev: History, Up: Introduction + +Building +======== + +Most readers of this document should already know how to build a tool by +running `configure' and `make'. This section may serve as a quick +introduction or reminder. + + Building a tool is normally as simple as running `configure' +followed by `make'. You should normally run `configure' from an empty +directory, using some path to refer to the `configure' script in the +source directory. The directory in which you run `configure' is called +the "object directory". + + In order to use a object directory which is different from the source +directory, you must be using the GNU version of `make', which has the +required `VPATH' support. Despite this restriction, using a different +object directory is highly recommended: + * It keeps the files generated during the build from cluttering up + your sources. + + * It permits you to remove the built files by simply removing the + entire build directory. + + * It permits you to build from the same sources with several sets of + configure options simultaneously. + + If you don't have GNU `make', you will have to run `configure' in +the source directory. All GNU packages should support this; in +particular, GNU packages should not assume the presence of GNU `make'. + + After running `configure', you can build the tools by running `make'. + + To install the tools, run `make install'. Installing the tools will +copy the programs and any required support files to the "installation +directory". The location of the installation directory is controlled +by `configure' options, as described below. + + In the Cygnus tree at present, the info files are built and +installed as a separate step. To build them, run `make info'. To +install them, run `make install-info'. + + All `configure' scripts support a wide variety of options. The most +interesting ones are `--with' and `--enable' options which are +generally specific to particular tools. You can usually use the +`--help' option to get a list of interesting options for a particular +configure script. + + The only generic options you are likely to use are the `--prefix' +and `--exec-prefix' options. These options are used to specify the +installation directory. + + The directory named by the `--prefix' option will hold machine +independent files such as info files. + + The directory named by the `--exec-prefix' option, which is normally +a subdirectory of the `--prefix' directory, will hold machine dependent +files such as executables. + + The default for `--prefix' is `/usr/local'. The default for +`--exec-prefix' is the value used for `--prefix'. + + The convention used in Cygnus releases is to use a `--prefix' option +of `/usr/cygnus/RELEASE', where RELEASE is the name of the release, and +to use a `--exec-prefix' option of `/usr/cygnus/RELEASE/H-HOST', where +HOST is the configuration name of the host system (*note Configuration +Names::). + + Do not use either the source or the object directory as the +installation directory. That will just lead to confusion. + + +File: configure.info, Node: Getting Started, Next: Files, Prev: Introduction, Up: Top + +Getting Started +*************** + +To start using the GNU configure and build system with your software +package, you must write three files, and you must run some tools to +manually generate additional files. + +* Menu: + +* Write configure.in:: Write configure.in. +* Write Makefile.am:: Write Makefile.am. +* Write acconfig.h:: Write acconfig.h. +* Generate files:: Generate files. +* Getting Started Example:: Example. + + +File: configure.info, Node: Write configure.in, Next: Write Makefile.am, Up: Getting Started + +Write configure.in +================== + +You must first write the file `configure.in'. This is an autoconf +input file, and the autoconf manual describes in detail what this file +should look like. + + You will write tests in your `configure.in' file to check for +conditions that may change from one system to another, such as the +presence of particular header files or functions. + + For example, not all systems support the `gettimeofday' function. +If you want to use the `gettimeofday' function when it is available, +and to use some other function when it is not, you would check for this +by putting `AC_CHECK_FUNCS(gettimeofday)' in `configure.in'. + + When the configure script is run at build time, this will arrange to +define the preprocessor macro `HAVE_GETTIMEOFDAY' to the value 1 if the +`gettimeofday' function is available, and to not define the macro at +all if the function is not available. Your code can then use `#ifdef' +to test whether it is safe to call `gettimeofday'. + + If you have an existing body of code, the `autoscan' program may +help identify potential portability problems, and hence configure tests +that you will want to use. *Note Invoking autoscan: (autoconf)Invoking +autoscan. + + Another handy tool for an existing body of code is `ifnames'. This +will show you all the preprocessor conditionals that the code already +uses. *Note Invoking ifnames: (autoconf)Invoking ifnames. + + Besides the portability tests which are specific to your particular +package, every `configure.in' file should contain the following macros. + +`AC_INIT' + This macro takes a single argument, which is the name of a file in + your package. For example, `AC_INIT(foo.c)'. + +`AC_PREREQ(VERSION)' + This macro is optional. It may be used to indicate the version of + `autoconf' that you are using. This will prevent users from + running an earlier version of `autoconf' and perhaps getting an + invalid `configure' script. For example, `AC_PREREQ(2.12)'. + +`AM_INIT_AUTOMAKE' + This macro takes two arguments: the name of the package, and a + version number. For example, `AM_INIT_AUTOMAKE(foo, 1.0)'. (This + macro is not needed if you are not using automake). + +`AM_CONFIG_HEADER' + This macro names the header file which will hold the preprocessor + macro definitions at run time. Normally this should be + `config.h'. Your sources would then use `#include "config.h"' to + include it. + + This macro may optionally name the input file for that header + file; by default, this is `config.h.in', but that file name works + poorly on DOS filesystems. Therefore, it is often better to name + it explicitly as `config.in'. + + This is what you should normally put in `configure.in': + AM_CONFIG_HEADER(config.h:config.in) + + (If you are not using automake, use `AC_CONFIG_HEADER' rather than + `AM_CONFIG_HEADER'). + +`AM_MAINTAINER_MODE' + This macro always appears in Cygnus configure scripts. Other + programs may or may not use it. + + If this macro is used, the `--enable-maintainer-mode' option is + required to enable automatic rebuilding of generated files used by + the configure system. This of course requires that developers be + aware of, and use, that option. + + If this macro is not used, then the generated files will always be + rebuilt automatically. This will cause problems if the wrong + versions of autoconf, automake, or others are in the builder's + `PATH'. + + (If you are not using automake, you do not need to use this macro). + +`AC_EXEEXT' + Either this macro or `AM_EXEEXT' always appears in Cygnus configure + files. Other programs may or may not use one of them. + + This macro looks for the executable suffix used on the host + system. On Unix systems, this is the empty string. On Windows + systems, this is `.exe'. This macro directs automake to use the + executable suffix as appropriate when creating programs. This + macro does not take any arguments. + + The `AC_EXEEXT' form is new, and is part of a Cygnus patch to + autoconf to support compiling with Visual C++. Older programs use + `AM_EXEEXT' instead. + + (Programs which do not use automake use neither `AC_EXEEXT' nor + `AM_EXEEXT'). + +`AC_PROG_CC' + If you are writing C code, you will normally want to use this + macro. It locates the C compiler to use. It does not take any + arguments. + + However, if this `configure.in' file is for a library which is to + be compiled by a cross compiler which may not fully work, then you + will not want to use `AC_PROG_CC'. Instead, you will want to use a + variant which does not call the macro `AC_PROG_CC_WORKS'. Examples + can be found in various `configure.in' files for libraries that are + compiled with cross compilers, such as libiberty or libgloss. + This is essentially a bug in autoconf, and there will probably be + a better workaround at some point. + +`AC_PROG_CXX' + If you are writing C++ code, you will want to use this macro. It + locates the C++ compiler to use. It does not take any arguments. + The same cross compiler comments apply as for `AC_PROG_CC'. + +`AM_PROG_LIBTOOL' + If you want to build libraries, and you want to permit them to be + shared, or you want to link against libraries which were built + using libtool, then you will need this macro. This macro is + required in order to use libtool. + + By default, this will cause all libraries to be built as shared + libraries. To prevent this-to change the default-use + `AM_DISABLE_SHARED' before `AM_PROG_LIBTOOL'. The configure + options `--enable-shared' and `--disable-shared' may be used to + override the default at build time. + +`AC_DEFINE(_GNU_SOURCE)' + GNU packages should normally include this line before any other + feature tests. This defines the macro `_GNU_SOURCE' when + compiling, which directs the libc header files to provide the + standard GNU system interfaces including all GNU extensions. If + this macro is not defined, certain GNU extensions may not be + available. + +`AC_OUTPUT' + This macro takes a list of file names which the configure process + should produce. This is normally a list of one or more `Makefile' + files in different directories. If your package lives entirely in + a single directory, you would use simply `AC_OUTPUT(Makefile)'. + If you also have, for example, a `lib' subdirectory, you would use + `AC_OUTPUT(Makefile lib/Makefile)'. + + If you want to use locally defined macros in your `configure.in' +file, then you will need to write a `acinclude.m4' file which defines +them (if not using automake, this file is called `aclocal.m4'). +Alternatively, you can put separate macros in an `m4' subdirectory, and +put `ACLOCAL_AMFLAGS = -I m4' in your `Makefile.am' file so that the +`aclocal' program will be able to find them. + + The different macro prefixes indicate which tool defines the macro. +Macros which start with `AC_' are part of autoconf. Macros which start +with `AM_' are provided by automake or libtool. + + +File: configure.info, Node: Write Makefile.am, Next: Write acconfig.h, Prev: Write configure.in, Up: Getting Started + +Write Makefile.am +================= + +You must write the file `Makefile.am'. This is an automake input file, +and the automake manual describes in detail what this file should look +like. + + The automake commands in `Makefile.am' mostly look like variable +assignments in a `Makefile'. automake recognizes special variable +names, and automatically add make rules to the output as needed. + + There will be one `Makefile.am' file for each directory in your +package. For each directory with subdirectories, the `Makefile.am' +file should contain the line + SUBDIRS = DIR DIR ... + +where each DIR is the name of a subdirectory. + + For each `Makefile.am', there should be a corresponding `Makefile' +in the `AC_OUTPUT' macro in `configure.in'. + + Every `Makefile.am' written at Cygnus should contain the line + AUTOMAKE_OPTIONS = cygnus + +This puts automake into Cygnus mode. See the automake manual for +details. + + You may to include the version number of `automake' that you are +using on the `AUTOMAKE_OPTIONS' line. For example, + AUTOMAKE_OPTIONS = cygnus 1.3 + +This will prevent users from running an earlier version of `automake' +and perhaps getting an invalid `Makefile.in'. + + If your package builds a program, then in the directory where that +program is built you will normally want a line like + bin_PROGRAMS = PROGRAM + +where PROGRAM is the name of the program. You will then want a line +like + PROGRAM_SOURCES = FILE FILE ... + +where each FILE is the name of a source file to link into the program +(e.g., `foo.c'). + + If your package builds a library, and you do not want the library to +ever be built as a shared library, then in the directory where that +library is built you will normally want a line like + lib_LIBRARIES = libNAME.a + +where `libNAME.a' is the name of the library. You will then want a +line like + libNAME_a_SOURCES = FILE FILE ... + +where each FILE is the name of a source file to add to the library. + + If your package builds a library, and you want to permit building the +library as a shared library, then in the directory where that library is +built you will normally want a line like + lib_LTLIBRARIES = libNAME.la + The use of `LTLIBRARIES', and the `.la' extension, indicate a +library to be built using libtool. As usual, you will then want a line +like + libNAME_la_SOURCES = FILE FILE ... + + The strings `bin' and `lib' that appear above in `bin_PROGRAMS' and +`lib_LIBRARIES' are not arbitrary. They refer to particular +directories, which may be set by the `--bindir' and `--libdir' options +to `configure'. If those options are not used, the default values are +based on the `--prefix' or `--exec-prefix' options to `configure'. It +is possible to use other names if the program or library should be +installed in some other directory. + + The `Makefile.am' file may also contain almost anything that may +appear in a normal `Makefile'. automake also supports many other +special variables, as well as conditionals. + + See the automake manual for more information. + + +File: configure.info, Node: Write acconfig.h, Next: Generate files, Prev: Write Makefile.am, Up: Getting Started + +Write acconfig.h +================ + +If you are generating a portability header file, (i.e., you are using +`AM_CONFIG_HEADER' in `configure.in'), then you will have to write a +`acconfig.h' file. It will have to contain the following lines. + + /* Name of package. */ + #undef PACKAGE + + /* Version of package. */ + #undef VERSION + + This requirement is really a bug in the system, and the requirement +may be eliminated at some later date. + + The `acconfig.h' file will also similar comment and `#undef' lines +for any unusual macros in the `configure.in' file, including any macro +which appears in a `AC_DEFINE' macro. + + In particular, if you are writing a GNU package and therefore include +`AC_DEFINE(_GNU_SOURCE)' in `configure.in' as suggested above, you will +need lines like this in `acconfig.h': + /* Enable GNU extensions. */ + #undef _GNU_SOURCE + + Normally the `autoheader' program will inform you of any such +requirements by printing an error message when it is run. However, if +you do anything particular odd in your `configure.in' file, you will +have to make sure that the right entries appear in `acconfig.h', since +otherwise the results of the tests may not be available in the +`config.h' file which your code will use. + + (Thee `PACKAGE' and `VERSION' lines are not required if you are not +using automake, and in that case you may not need a `acconfig.h' file +at all). + + +File: configure.info, Node: Generate files, Next: Getting Started Example, Prev: Write acconfig.h, Up: Getting Started + +Generate files +============== + +Once you have written `configure.in', `Makefile.am', `acconfig.h', and +possibly `acinclude.m4', you must use autoconf and automake programs to +produce the first versions of the generated files. This is done by +executing the following sequence of commands. + + aclocal + autoconf + autoheader + automake + + The `aclocal' and `automake' commands are part of the automake +package, and the `autoconf' and `autoheader' commands are part of the +autoconf package. + + If you are using a `m4' subdirectory for your macros, you will need +to use the `-I m4' option when you run `aclocal'. + + If you are not using the Cygnus tree, use the `-a' option when +running `automake' command in order to copy the required support files +into your source directory. + + If you are using libtool, you must build and install the libtool +package with the same `--prefix' and `--exec-prefix' options as you +used with the autoconf and automake packages. You must do this before +running any of the above commands. If you are not using the Cygnus +tree, you will need to run the `libtoolize' program to copy the libtool +support files into your directory. + + Once you have managed to run these commands without getting any +errors, you should create a new empty directory, and run the `configure' +script which will have been created by `autoconf' with the +`--enable-maintainer-mode' option. This will give you a set of +Makefiles which will include rules to automatically rebuild all the +generated files. + + After doing that, whenever you have changed some of the input files +and want to regenerated the other files, go to your object directory +and run `make'. Doing this is more reliable than trying to rebuild the +files manually, because there are complex order dependencies and it is +easy to forget something. + + +File: configure.info, Node: Getting Started Example, Prev: Generate files, Up: Getting Started + +Example +======= + +Let's consider a trivial example. + + Suppose we want to write a simple version of `touch'. Our program, +which we will call `poke', will take a single file name argument, and +use the `utime' system call to set the modification and access times of +the file to the current time. We want this program to be highly +portable. + + We'll first see what this looks like without using autoconf and +automake, and then see what it looks like with them. + +* Menu: + +* Getting Started Example 1:: First Try. +* Getting Started Example 2:: Second Try. +* Getting Started Example 3:: Third Try. +* Generate Files in Example:: Generate Files. + + +File: configure.info, Node: Getting Started Example 1, Next: Getting Started Example 2, Up: Getting Started Example + +First Try +--------- + +Here is our first try at `poke.c'. Note that we've written it without +ANSI/ISO C prototypes, since we want it to be highly portable. + + #include <stdio.h> + #include <stdlib.h> + #include <sys/types.h> + #include <utime.h> + + int + main (argc, argv) + int argc; + char **argv; + { + if (argc != 2) + { + fprintf (stderr, "Usage: poke file\n"); + exit (1); + } + + if (utime (argv[1], NULL) < 0) + { + perror ("utime"); + exit (1); + } + + exit (0); + } + + We also write a simple `Makefile'. + + CC = gcc + CFLAGS = -g -O2 + + all: poke + + poke: poke.o + $(CC) -o poke $(CFLAGS) $(LDFLAGS) poke.o + + So far, so good. + + Unfortunately, there are a few problems. + + On older Unix systems derived from BSD 4.3, the `utime' system call +does not accept a second argument of `NULL'. On those systems, we need +to pass a pointer to `struct utimbuf' structure. Unfortunately, even +older systems don't define that structure; on those systems, we need to +pass an array of two `long' values. + + The header file `stdlib.h' was invented by ANSI C, and older systems +don't have a copy. We included it above to get a declaration of `exit'. + + We can find some of these portability problems by running +`autoscan', which will create a `configure.scan' file which we can use +as a prototype for our `configure.in' file. I won't show the output, +but it will notice the potential problems with `utime' and `stdlib.h'. + + In our `Makefile', we don't provide any way to install the program. +This doesn't matter much for such a simple example, but a real program +will need an `install' target. For that matter, we will also want a +`clean' target. + + +File: configure.info, Node: Getting Started Example 2, Next: Getting Started Example 3, Prev: Getting Started Example 1, Up: Getting Started Example + +Second Try +---------- + +Here is our second try at this program. + + We modify `poke.c' to use preprocessor macros to control what +features are available. (I've cheated a bit by using the same macro +names which autoconf will use). + + #include <stdio.h> + + #ifdef STDC_HEADERS + #include <stdlib.h> + #endif + + #include <sys/types.h> + + #ifdef HAVE_UTIME_H + #include <utime.h> + #endif + + #ifndef HAVE_UTIME_NULL + + #include <time.h> + + #ifndef HAVE_STRUCT_UTIMBUF + + struct utimbuf + { + long actime; + long modtime; + }; + + #endif + + static int + utime_now (file) + char *file; + { + struct utimbuf now; + + now.actime = now.modtime = time (NULL); + return utime (file, &now); + } + + #define utime(f, p) utime_now (f) + + #endif /* HAVE_UTIME_NULL */ + + int + main (argc, argv) + int argc; + char **argv; + { + if (argc != 2) + { + fprintf (stderr, "Usage: poke file\n"); + exit (1); + } + + if (utime (argv[1], NULL) < 0) + { + perror ("utime"); + exit (1); + } + + exit (0); + } + + Here is the associated `Makefile'. We've added support for the +preprocessor flags we use. We've also added `install' and `clean' +targets. + + # Set this to your installation directory. + bindir = /usr/local/bin + + # Uncomment this if you have the standard ANSI/ISO C header files. + # STDC_HDRS = -DSTDC_HEADERS + + # Uncomment this if you have utime.h. + # UTIME_H = -DHAVE_UTIME_H + + # Uncomment this if utime (FILE, NULL) works on your system. + # UTIME_NULL = -DHAVE_UTIME_NULL + + # Uncomment this if struct utimbuf is defined in utime.h. + # UTIMBUF = -DHAVE_STRUCT_UTIMBUF + + CC = gcc + CFLAGS = -g -O2 + + ALL_CFLAGS = $(STDC_HDRS) $(UTIME_H) $(UTIME_NULL) $(UTIMBUF) $(CFLAGS) + + all: poke + + poke: poke.o + $(CC) -o poke $(ALL_CFLAGS) $(LDFLAGS) poke.o + + .c.o: + $(CC) -c $(ALL_CFLAGS) poke.c + + install: poke + cp poke $(bindir)/poke + + clean: + rm poke poke.o + + Some problems with this approach should be clear. + + Users who want to compile poke will have to know how `utime' works +on their systems, so that they can uncomment the `Makefile' correctly. + + The installation is done using `cp', but many systems have an +`install' program which may be used, and which supports optional +features such as stripping debugging information out of the installed +binary. + + The use of `Makefile' variables like `CC', `CFLAGS' and `LDFLAGS' +follows the requirements of the GNU standards. This is convenient for +all packages, since it reduces surprises for users. However, it is +easy to get the details wrong, and wind up with a slightly nonstandard +distribution. + + +File: configure.info, Node: Getting Started Example 3, Next: Generate Files in Example, Prev: Getting Started Example 2, Up: Getting Started Example + +Third Try +--------- + +For our third try at this program, we will write a `configure.in' +script to discover the configuration features on the host system, rather +than requiring the user to edit the `Makefile'. We will also write a +`Makefile.am' rather than a `Makefile'. + + The only change to `poke.c' is to add a line at the start of the +file: + #include "config.h" + + The new `configure.in' file is as follows. + + AC_INIT(poke.c) + AM_INIT_AUTOMAKE(poke, 1.0) + AM_CONFIG_HEADER(config.h:config.in) + AC_PROG_CC + AC_HEADER_STDC + AC_CHECK_HEADERS(utime.h) + AC_EGREP_HEADER(utimbuf, utime.h, AC_DEFINE(HAVE_STRUCT_UTIMBUF)) + AC_FUNC_UTIME_NULL + AC_OUTPUT(Makefile) + + The first four macros in this file, and the last one, were described +above; see *Note Write configure.in::. If we omit these macros, then +when we run `automake' we will get a reminder that we need them. + + The other macros are standard autoconf macros. + +`AC_HEADER_STDC' + Check for standard C headers. + +`AC_CHECK_HEADERS' + Check whether a particular header file exists. + +`AC_EGREP_HEADER' + Check for a particular string in a particular header file, in this + case checking for `utimbuf' in `utime.h'. + +`AC_FUNC_UTIME_NULL' + Check whether `utime' accepts a NULL second argument to set the + file change time to the current time. + + See the autoconf manual for a more complete description. + + The new `Makefile.am' file is as follows. Note how simple this is +compared to our earlier `Makefile'. + + bin_PROGRAMS = poke + + poke_SOURCES = poke.c + + This means that we should build a single program name `poke'. It +should be installed in the binary directory, which we called `bindir' +earlier. The program `poke' is built from the source file `poke.c'. + + We must also write a `acconfig.h' file. Besides `PACKAGE' and +`VERSION', which must be mentioned for all packages which use automake, +we must include `HAVE_STRUCT_UTIMBUF', since we mentioned it in an +`AC_DEFINE'. + + /* Name of package. */ + #undef PACKAGE + + /* Version of package. */ + #undef VERSION + + /* Whether utime.h defines struct utimbuf. */ + #undef HAVE_STRUCT_UTIMBUF + + +File: configure.info, Node: Generate Files in Example, Prev: Getting Started Example 3, Up: Getting Started Example + +Generate Files +-------------- + +We must now generate the other files, using the following commands. + + aclocal + autoconf + autoheader + automake + + When we run `autoheader', it will remind us of any macros we forgot +to add to `acconfig.h'. + + When we run `automake', it will want to add some files to our +distribution. It will add them automatically if we use the +`--add-missing' option. + + By default, `automake' will run in GNU mode, which means that it +will want us to create certain additional files; as of this writing, it +will want `NEWS', `README', `AUTHORS', and `ChangeLog', all of which +are files which should appear in a standard GNU distribution. We can +either add those files, or run `automake' with the `--foreign' option. + + Running these tools will generate the following files, all of which +are described in the next chapter. + + * `aclocal.m4' + + * `configure' + + * `config.in' + + * `Makefile.in' + + * `stamp-h.in' + + +File: configure.info, Node: Files, Next: Configuration Names, Prev: Getting Started, Up: Top + +Files +***** + +As was seen in the previous chapter, the GNU configure and build system +uses a number of different files. The developer must write a few files. +The others are generated by various tools. + + The system is rather flexible, and can be used in many different +ways. In describing the files that it uses, I will describe the common +case, and mention some other cases that may arise. + +* Menu: + +* Developer Files:: Developer Files. +* Build Files:: Build Files. +* Support Files:: Support Files. + + +File: configure.info, Node: Developer Files, Next: Build Files, Up: Files + +Developer Files +=============== + +This section describes the files written or generated by the developer +of a package. + +* Menu: + +* Developer Files Picture:: Developer Files Picture. +* Written Developer Files:: Written Developer Files. +* Generated Developer Files:: Generated Developer Files. + + +File: configure.info, Node: Developer Files Picture, Next: Written Developer Files, Up: Developer Files + +Developer Files Picture +----------------------- + +Here is a picture of the files which are written by the developer, the +generated files which would be included with a complete source +distribution, and the tools which create those files. The file names +are plain text and the tool names are enclosed by `*' characters (e.g., +`autoheader' is the name of a tool, not the name of a file). + + + | | | + | --------------+---------------------- | + | | | | | + v v | acinclude.m4 | | + *autoheader* | | v v + | | v --->*automake* + v |--->*aclocal* | | + config.in | | | v + | v | Makefile.in + | aclocal.m4--- + | | + v v + *autoconf* + | + v + configure +" + + +File: configure.info, Node: Written Developer Files, Next: Generated Developer Files, Prev: Developer Files Picture, Up: Developer Files + +Written Developer Files +----------------------- + +The following files would be written by the developer. + +`configure.in' + This is the configuration script. This script contains + invocations of autoconf macros. It may also contain ordinary + shell script code. This file will contain feature tests for + portability issues. The last thing in the file will normally be + an `AC_OUTPUT' macro listing which files to create when the + builder runs the configure script. This file is always required + when using the GNU configure system. *Note Write configure.in::. + +`Makefile.am' + This is the automake input file. It describes how the code should + be built. It consists of definitions of automake variables. It + may also contain ordinary Makefile targets. This file is only + needed when using automake (newer tools normally use automake, but + there are still older tools which have not been converted, in + which the developer writes `Makefile.in' directly). *Note Write + Makefile.am::. + +`acconfig.h' + When the configure script creates a portability header file, by + using `AM_CONFIG_HEADER' (or, if not using automake, + `AC_CONFIG_HEADER'), this file is used to describe macros which are + not recognized by the `autoheader' command. This is normally a + fairly uninteresting file, consisting of a collection of `#undef' + lines with comments. Normally any call to `AC_DEFINE' in + `configure.in' will require a line in this file. *Note Write + acconfig.h::. + +`acinclude.m4' + This file is not always required. It defines local autoconf + macros. These macros may then be used in `configure.in'. If you + don't need any local autoconf macros, then you don't need this + file at all. In fact, in general, you never need local autoconf + macros, since you can put everything in `configure.in', but + sometimes a local macro is convenient. + + Newer tools may omit `acinclude.m4', and instead use a + subdirectory, typically named `m4', and define `ACLOCAL_AMFLAGS = + -I m4' in `Makefile.am' to force `aclocal' to look there for macro + definitions. The macro definitions are then placed in separate + files in that directory. + + The `acinclude.m4' file is only used when using automake; in older + tools, the developer writes `aclocal.m4' directly, if it is needed. + + +File: configure.info, Node: Generated Developer Files, Prev: Written Developer Files, Up: Developer Files + +Generated Developer Files +------------------------- + +The following files would be generated by the developer. + + When using automake, these files are normally not generated manually +after the first time. Instead, the generated `Makefile' contains rules +to automatically rebuild the files as required. When +`AM_MAINTAINER_MODE' is used in `configure.in' (the normal case in +Cygnus code), the automatic rebuilding rules will only be defined if +you configure using the `--enable-maintainer-mode' option. + + When using automatic rebuilding, it is important to ensure that all +the various tools have been built and installed on your `PATH'. Using +automatic rebuilding is highly recommended, so much so that I'm not +going to explain what you have to do if you don't use it. + +`configure' + This is the configure script which will be run when building the + package. This is generated by `autoconf' from `configure.in' and + `aclocal.m4'. This is a shell script. + +`Makefile.in' + This is the file which the configure script will turn into the + `Makefile' at build time. This file is generated by `automake' + from `Makefile.am'. If you aren't using automake, you must write + this file yourself. This file is pretty much a normal `Makefile', + with some configure substitutions for certain variables. + +`aclocal.m4' + This file is created by the `aclocal' program, based on the + contents of `configure.in' and `acinclude.m4' (or, as noted in the + description of `acinclude.m4' above, on the contents of an `m4' + subdirectory). This file contains definitions of autoconf macros + which `autoconf' will use when generating the file `configure'. + These autoconf macros may be defined by you in `acinclude.m4' or + they may be defined by other packages such as automake, libtool or + gettext. If you aren't using automake, you will normally write + this file yourself; in that case, if `configure.in' uses only + standard autoconf macros, this file will not be needed at all. + +`config.in' + This file is created by `autoheader' based on `acconfig.h' and + `configure.in'. At build time, the configure script will define + some of the macros in it to create `config.h', which may then be + included by your program. This permits your C code to use + preprocessor conditionals to change its behaviour based on the + characteristics of the host system. This file may also be called + `config.h.in'. + +`stamp.h-in' + This rather uninteresting file, which I omitted from the picture, + is generated by `automake'. It always contains the string + `timestamp'. It is used as a timestamp file indicating whether + `config.in' is up to date. Using a timestamp file means that + `config.in' can be marked as up to date without actually changing + its modification time. This is useful since `config.in' depends + upon `configure.in', but it is easy to change `configure.in' in a + way which does not affect `config.in'. + + +File: configure.info, Node: Build Files, Next: Support Files, Prev: Developer Files, Up: Files + +Build Files +=========== + +This section describes the files which are created at configure and +build time. These are the files which somebody who builds the package +will see. + + Of course, the developer will also build the package. The +distinction between developer files and build files is not that the +developer does not see the build files, but that somebody who only +builds the package does not have to worry about the developer files. + +* Menu: + +* Build Files Picture:: Build Files Picture. +* Build Files Description:: Build Files Description. + + +File: configure.info, Node: Build Files Picture, Next: Build Files Description, Up: Build Files + +Build Files Picture +------------------- + +Here is a picture of the files which will be created at build time. +`config.status' is both a created file and a shell script which is run +to create other files, and the picture attempts to show that. + + + | | | + | v | + | config.status | + | | | + *config.status*<======+==========>*config.status* + | | + v v + config.h Makefile +" + + +File: configure.info, Node: Build Files Description, Prev: Build Files Picture, Up: Build Files + +Build Files Description +----------------------- + +This is a description of the files which are created at build time. + +`config.status' + The first step in building a package is to run the `configure' + script. The `configure' script will create the file + `config.status', which is itself a shell script. When you first + run `configure', it will automatically run `config.status'. An + `Makefile' derived from an automake generated `Makefile.in' will + contain rules to automatically run `config.status' again when + necessary to recreate certain files if their inputs change. + +`Makefile' + This is the file which make will read to build the program. The + `config.status' script will transform `Makefile.in' into + `Makefile'. + +`config.h' + This file defines C preprocessor macros which C code can use to + adjust its behaviour on different systems. The `config.status' + script will transform `config.in' into `config.h'. + +`config.cache' + This file did not fit neatly into the picture, and I omitted it. + It is used by the `configure' script to cache results between + runs. This can be an important speedup. If you modify + `configure.in' in such a way that the results of old tests should + change (perhaps you have added a new library to `LDFLAGS'), then + you will have to remove `config.cache' to force the tests to be + rerun. + + The autoconf manual explains how to set up a site specific cache + file. This can speed up running `configure' scripts on your + system. + +`stamp.h' + This file, which I omitted from the picture, is similar to + `stamp-h.in'. It is used as a timestamp file indicating whether + `config.h' is up to date. This is useful since `config.h' depends + upon `config.status', but it is easy for `config.status' to change + in a way which does not affect `config.h'. + + +File: configure.info, Node: Support Files, Prev: Build Files, Up: Files + +Support Files +============= + +The GNU configure and build system requires several support files to be +included with your distribution. You do not normally need to concern +yourself with these. If you are using the Cygnus tree, most are already +present. Otherwise, they will be installed with your source by +`automake' (with the `--add-missing' option) and `libtoolize'. + + You don't have to put the support files in the top level directory. +You can put them in a subdirectory, and use the `AC_CONFIG_AUX_DIR' +macro in `configure.in' to tell `automake' and the `configure' script +where they are. + + In this section, I describe the support files, so that you can know +what they are and why they are there. + +`ABOUT-NLS' + Added by automake if you are using gettext. This is a + documentation file about the gettext project. + +`ansi2knr.c' + Used by an automake generated `Makefile' if you put `ansi2knr' in + `AUTOMAKE_OPTIONS' in `Makefile.am'. This permits compiling ANSI + C code with a K&R C compiler. + +`ansi2knr.1' + The man page which goes with `ansi2knr.c'. + +`config.guess' + A shell script which determines the configuration name for the + system on which it is run. + +`config.sub' + A shell script which canonicalizes a configuration name entered by + a user. + +`elisp-comp' + Used to compile Emacs LISP files. + +`install-sh' + A shell script which installs a program. This is used if the + configure script can not find an install binary. + +`ltconfig' + Used by libtool. This is a shell script which configures libtool + for the particular system on which it is used. + +`ltmain.sh' + Used by libtool. This is the actual libtool script which is used, + after it is configured by `ltconfig' to build a library. + +`mdate-sh' + A shell script used by an automake generated `Makefile' to pretty + print the modification time of a file. This is used to maintain + version numbers for texinfo files. + +`missing' + A shell script used if some tool is missing entirely. This is + used by an automake generated `Makefile' to avoid certain sorts of + timestamp problems. + +`mkinstalldirs' + A shell script which creates a directory, including all parent + directories. This is used by an automake generated `Makefile' + during installation. + +`texinfo.tex' + Required if you have any texinfo files. This is used when + converting Texinfo files into DVI using `texi2dvi' and TeX. + +`ylwrap' + A shell script used by an automake generated `Makefile' to run + programs like `bison', `yacc', `flex', and `lex'. These programs + default to producing output files with a fixed name, and the + `ylwrap' script runs them in a subdirectory to avoid file name + conflicts when using a parallel make program. + + +File: configure.info, Node: Configuration Names, Next: Cross Compilation Tools, Prev: Files, Up: Top + +Configuration Names +******************* + +The GNU configure system names all systems using a "configuration +name". All such names used to be triplets (they may now contain four +parts in certain cases), and the term "configuration triplet" is still +seen. + +* Menu: + +* Configuration Name Definition:: Configuration Name Definition. +* Using Configuration Names:: Using Configuration Names. + + +File: configure.info, Node: Configuration Name Definition, Next: Using Configuration Names, Up: Configuration Names + +Configuration Name Definition +============================= + +This is a string of the form CPU-MANUFACTURER-OPERATING_SYSTEM. In +some cases, this is extended to a four part form: +CPU-MANUFACTURER-KERNEL-OPERATING_SYSTEM. + + When using a configuration name in a configure option, it is normally +not necessary to specify an entire name. In particular, the +MANUFACTURER field is often omitted, leading to strings such as +`i386-linux' or `sparc-sunos'. The shell script `config.sub' will +translate these shortened strings into the canonical form. autoconf +will arrange for `config.sub' to be run automatically when it is needed. + + The fields of a configuration name are as follows: + +CPU + The type of processor. This is typically something like `i386' or + `sparc'. More specific variants are used as well, such as + `mipsel' to indicate a little endian MIPS processor. + +MANUFACTURER + A somewhat freeform field which indicates the manufacturer of the + system. This is often simply `unknown'. Other common strings are + `pc' for an IBM PC compatible system, or the name of a workstation + vendor, such as `sun'. + +OPERATING_SYSTEM + The name of the operating system which is run on the system. This + will be something like `solaris2.5' or `irix6.3'. There is no + particular restriction on the version number, and strings like + `aix4.1.4.0' are seen. For an embedded system, which has no + operating system, this field normally indicates the type of object + file format, such as `elf' or `coff'. + +KERNEL + This is used mainly for GNU/Linux. A typical GNU/Linux + configuration name is `i586-pc-linux-gnulibc1'. In this case the + kernel, `linux', is separated from the operating system, + `gnulibc1'. + + The shell script `config.guess' will normally print the correct +configuration name for the system on which it is run. It does by +running `uname' and by examining other characteristics of the system. + + Because `config.guess' can normally determine the configuration name +for a machine, it is normally only necessary to specify a configuration +name when building a cross-compiler or when building using a +cross-compiler. + + +File: configure.info, Node: Using Configuration Names, Prev: Configuration Name Definition, Up: Configuration Names + +Using Configuration Names +========================= + +A configure script will sometimes have to make a decision based on a +configuration name. You will need to do this if you have to compile +code differently based on something which can not be tested using a +standard autoconf feature test. + + It is normally better to test for particular features, rather than to +test for a particular system. This is because as Unix evolves, +different systems copy features from one another. Even if you need to +determine whether the feature is supported based on a configuration +name, you should define a macro which describes the feature, rather than +defining a macro which describes the particular system you are on. + + Testing for a particular system is normally done using a case +statement in `configure.in'. The case statement might look something +like the following, assuming that `host' is a shell variable holding a +canonical configuration name (which will be the case if `configure.in' +uses the `AC_CANONICAL_HOST' or `AC_CANONICAL_SYSTEM' macro). + + case "${host}" in + i[3-7]86-*-linux-gnu*) do something ;; + sparc*-sun-solaris2.[56789]*) do something ;; + sparc*-sun-solaris*) do something ;; + mips*-*-elf*) do something ;; + esac + + It is particularly important to use `*' after the operating system +field, in order to match the version number which will be generated by +`config.guess'. + + In most cases you must be careful to match a range of processor +types. For most processor families, a trailing `*' suffices, as in +`mips*' above. For the i386 family, something along the lines of +`i[3-7]86' suffices at present. For the m68k family, you will need +something like `m68*'. Of course, if you do not need to match on the +processor, it is simpler to just replace the entire field by a `*', as +in `*-*-irix*'. + + +File: configure.info, Node: Cross Compilation Tools, Next: Canadian Cross, Prev: Configuration Names, Up: Top + +Cross Compilation Tools +*********************** + +The GNU configure and build system can be used to build "cross +compilation" tools. A cross compilation tool is a tool which runs on +one system and produces code which runs on another system. + +* Menu: + +* Cross Compilation Concepts:: Cross Compilation Concepts. +* Host and Target:: Host and Target. +* Using the Host Type:: Using the Host Type. +* Specifying the Target:: Specifying the Target. +* Using the Target Type:: Using the Target Type. +* Cross Tools in the Cygnus Tree:: Cross Tools in the Cygnus Tree + + +File: configure.info, Node: Cross Compilation Concepts, Next: Host and Target, Up: Cross Compilation Tools + +Cross Compilation Concepts +========================== + +A compiler which produces programs which run on a different system is a +cross compilation compiler, or simply a "cross compiler". Similarly, +we speak of cross assemblers, cross linkers, etc. + + In the normal case, a compiler produces code which runs on the same +system as the one on which the compiler runs. When it is necessary to +distinguish this case from the cross compilation case, such a compiler +is called a "native compiler". Similarly, we speak of native +assemblers, etc. + + Although the debugger is not strictly speaking a compilation tool, +it is nevertheless meaningful to speak of a cross debugger: a debugger +which is used to debug code which runs on another system. Everything +that is said below about configuring cross compilation tools applies to +the debugger as well. + + +File: configure.info, Node: Host and Target, Next: Using the Host Type, Prev: Cross Compilation Concepts, Up: Cross Compilation Tools + +Host and Target +=============== + +When building cross compilation tools, there are two different systems +involved: the system on which the tools will run, and the system for +which the tools generate code. + + The system on which the tools will run is called the "host" system. + + The system for which the tools generate code is called the "target" +system. + + For example, suppose you have a compiler which runs on a GNU/Linux +system and generates ELF programs for a MIPS embedded system. In this +case the GNU/Linux system is the host, and the MIPS ELF system is the +target. Such a compiler could be called a GNU/Linux cross MIPS ELF +compiler, or, equivalently, a `i386-linux-gnu' cross `mips-elf' +compiler. + + Naturally, most programs are not cross compilation tools. For those +programs, it does not make sense to speak of a target. It only makes +sense to speak of a target for tools like `gcc' or the `binutils' which +actually produce running code. For example, it does not make sense to +speak of the target of a tool like `bison' or `make'. + + Most cross compilation tools can also serve as native tools. For a +native compilation tool, it is still meaningful to speak of a target. +For a native tool, the target is the same as the host. For example, for +a GNU/Linux native compiler, the host is GNU/Linux, and the target is +also GNU/Linux. + + +File: configure.info, Node: Using the Host Type, Next: Specifying the Target, Prev: Host and Target, Up: Cross Compilation Tools + +Using the Host Type +=================== + +In almost all cases the host system is the system on which you run the +`configure' script, and on which you build the tools (for the case when +they differ, *note Canadian Cross::). + + If your configure script needs to know the configuration name of the +host system, and the package is not a cross compilation tool and +therefore does not have a target, put `AC_CANONICAL_HOST' in +`configure.in'. This macro will arrange to define a few shell +variables when the `configure' script is run. + +`host' + The canonical configuration name of the host. This will normally + be determined by running the `config.guess' shell script, although + the user is permitted to override this by using an explicit + `--host' option. + +`host_alias' + In the unusual case that the user used an explicit `--host' option, + this will be the argument to `--host'. In the normal case, this + will be the same as the `host' variable. + +`host_cpu' +`host_vendor' +`host_os' + The first three parts of the canonical configuration name. + + The shell variables may be used by putting shell code in +`configure.in'. For an example, see *Note Using Configuration Names::. + + +File: configure.info, Node: Specifying the Target, Next: Using the Target Type, Prev: Using the Host Type, Up: Cross Compilation Tools + +Specifying the Target +===================== + +By default, the `configure' script will assume that the target is the +same as the host. This is the more common case; for example, it leads +to a native compiler rather than a cross compiler. + + If you want to build a cross compilation tool, you must specify the +target explicitly by using the `--target' option when you run +`configure'. The argument to `--target' is the configuration name of +the system for which you wish to generate code. *Note Configuration +Names::. + + For example, to build tools which generate code for a MIPS ELF +embedded system, you would use `--target mips-elf'. + + +File: configure.info, Node: Using the Target Type, Next: Cross Tools in the Cygnus Tree, Prev: Specifying the Target, Up: Cross Compilation Tools + +Using the Target Type +===================== + +When writing `configure.in' for a cross compilation tool, you will need +to use information about the target. To do this, put +`AC_CANONICAL_SYSTEM' in `configure.in'. + + `AC_CANONICAL_SYSTEM' will look for a `--target' option and +canonicalize it using the `config.sub' shell script. It will also run +`AC_CANONICAL_HOST' (*note Using the Host Type::). + + The target type will be recorded in the following shell variables. +Note that the host versions of these variables will also be defined by +`AC_CANONICAL_HOST'. + +`target' + The canonical configuration name of the target. + +`target_alias' + The argument to the `--target' option. If the user did not specify + a `--target' option, this will be the same as `host_alias'. + +`target_cpu' +`target_vendor' +`target_os' + The first three parts of the canonical target configuration name. + + Note that if `host' and `target' are the same string, you can assume +a native configuration. If they are different, you can assume a cross +configuration. + + It is arguably possible for `host' and `target' to represent the +same system, but for the strings to not be identical. For example, if +`config.guess' returns `sparc-sun-sunos4.1.4', and somebody configures +with `--target sparc-sun-sunos4.1', then the slight differences between +the two versions of SunOS may be unimportant for your tool. However, +in the general case it can be quite difficult to determine whether the +differences between two configuration names are significant or not. +Therefore, by convention, if the user specifies a `--target' option +without specifying a `--host' option, it is assumed that the user wants +to configure a cross compilation tool. + + The variables `target' and `target_alias' should be handled +differently. + + In general, whenever the user may actually see a string, +`target_alias' should be used. This includes anything which may appear +in the file system, such as a directory name or part of a tool name. +It also includes any tool output, unless it is clearly labelled as the +canonical target configuration name. This permits the user to use the +`--target' option to specify how the tool will appear to the outside +world. + + On the other hand, when checking for characteristics of the target +system, `target' should be used. This is because a wide variety of +`--target' options may map into the same canonical configuration name. +You should not attempt to duplicate the canonicalization done by +`config.sub' in your own code. + + By convention, cross tools are installed with a prefix of the +argument used with the `--target' option, also known as `target_alias' +(*note Using the Target Type::). If the user does not use the +`--target' option, and thus is building a native tool, no prefix is +used. + + For example, if gcc is configured with `--target mips-elf', then the +installed binary will be named `mips-elf-gcc'. If gcc is configured +without a `--target' option, then the installed binary will be named +`gcc'. + + The autoconf macro `AC_ARG_PROGRAM' will handle this for you. If +you are using automake, no more need be done; the programs will +automatically be installed with the correct prefixes. Otherwise, see +the autoconf documentation for `AC_ARG_PROGRAM'. + + +File: configure.info, Node: Cross Tools in the Cygnus Tree, Prev: Using the Target Type, Up: Cross Compilation Tools + +Cross Tools in the Cygnus Tree +============================== + +The Cygnus tree is used for various packages including gdb, the GNU +binutils, and egcs. It is also, of course, used for Cygnus releases. + + In the Cygnus tree, the top level `configure' script uses the old +Cygnus configure system, not autoconf. The top level `Makefile.in' is +written to build packages based on what is in the source tree, and +supports building a large number of tools in a single +`configure'/`make' step. + + The Cygnus tree may be configured with a `--target' option. The +`--target' option applies recursively to every subdirectory, and +permits building an entire set of cross tools at once. + +* Menu: + +* Host and Target Libraries:: Host and Target Libraries. +* Target Library Configure Scripts:: Target Library Configure Scripts. +* Make Targets in Cygnus Tree:: Make Targets in Cygnus Tree. +* Target libiberty:: Target libiberty + + +File: configure.info, Node: Host and Target Libraries, Next: Target Library Configure Scripts, Up: Cross Tools in the Cygnus Tree + +Host and Target Libraries +------------------------- + +The Cygnus tree distinguishes host libraries from target libraries. + + Host libraries are built with the compiler used to build the programs +which run on the host, which is called the host compiler. This includes +libraries such as `bfd' and `tcl'. These libraries are built with the +host compiler, and are linked into programs like the binutils or gcc +which run on the host. + + Target libraries are built with the target compiler. If gcc is +present in the source tree, then the target compiler is the gcc that is +built using the host compiler. Target libraries are libraries such as +`newlib' and `libstdc++'. These libraries are not linked into the host +programs, but are instead made available for use with programs built +with the target compiler. + + For the rest of this section, assume that gcc is present in the +source tree, so that it will be used to build the target libraries. + + There is a complication here. The configure process needs to know +which compiler you are going to use to build a tool; otherwise, the +feature tests will not work correctly. The Cygnus tree handles this by +not configuring the target libraries until the target compiler is +built. In order to permit everything to build using a single +`configure'/`make', the configuration of the target libraries is +actually triggered during the make step. + + When the target libraries are configured, the `--target' option is +not used. Instead, the `--host' option is used with the argument of +the `--target' option for the overall configuration. If no `--target' +option was used for the overall configuration, the `--host' option will +be passed with the output of the `config.guess' shell script. Any +`--build' option is passed down unchanged. + + This translation of configuration options is done because since the +target libraries are compiled with the target compiler, they are being +built in order to run on the target of the overall configuration. By +the definition of host, this means that their host system is the same as +the target system of the overall configuration. + + The same process is used for both a native configuration and a cross +configuration. Even when using a native configuration, the target +libraries will be configured and built using the newly built compiler. +This is particularly important for the C++ libraries, since there is no +reason to assume that the C++ compiler used to build the host tools (if +there even is one) uses the same ABI as the g++ compiler which will be +used to build the target libraries. + + There is one difference between a native configuration and a cross +configuration. In a native configuration, the target libraries are +normally configured and built as siblings of the host tools. In a cross +configuration, the target libraries are normally built in a subdirectory +whose name is the argument to `--target'. This is mainly for +historical reasons. + + To summarize, running `configure' in the Cygnus tree configures all +the host libraries and tools, but does not configure any of the target +libraries. Running `make' then does the following steps: + + * Build the host libraries. + + * Build the host programs, including gcc. Note that we call gcc + both a host program (since it runs on the host) and a target + compiler (since it generates code for the target). + + * Using the newly built target compiler, configure the target + libraries. + + * Build the target libraries. + + The steps need not be done in precisely this order, since they are +actually controlled by `Makefile' targets. + + +File: configure.info, Node: Target Library Configure Scripts, Next: Make Targets in Cygnus Tree, Prev: Host and Target Libraries, Up: Cross Tools in the Cygnus Tree + +Target Library Configure Scripts +-------------------------------- + +There are a few things you must know in order to write a configure +script for a target library. This is just a quick sketch, and beginners +shouldn't worry if they don't follow everything here. + + The target libraries are configured and built using a newly built +target compiler. There may not be any startup files or libraries for +this target compiler. In fact, those files will probably be built as +part of some target library, which naturally means that they will not +exist when your target library is configured. + + This means that the configure script for a target library may not use +any test which requires doing a link. This unfortunately includes many +useful autoconf macros, such as `AC_CHECK_FUNCS'. autoconf macros +which do a compile but not a link, such as `AC_CHECK_HEADERS', may be +used. + + This is a severe restriction, but normally not a fatal one, as target +libraries can often assume the presence of other target libraries, and +thus know which functions will be available. + + As of this writing, the autoconf macro `AC_PROG_CC' does a link to +make sure that the compiler works. This may fail in a target library, +so target libraries must use a different set of macros to locate the +compiler. See the `configure.in' file in a directory like `libiberty' +or `libgloss' for an example. + + As noted in the previous section, target libraries are sometimes +built in directories which are siblings to the host tools, and are +sometimes built in a subdirectory. The `--with-target-subdir' configure +option will be passed when the library is configured. Its value will be +an empty string if the target library is a sibling. Its value will be +the name of the subdirectory if the target library is in a subdirectory. + + If the overall build is not a native build (i.e., the overall +configure used the `--target' option), then the library will be +configured with the `--with-cross-host' option. The value of this +option will be the host system of the overall build. Recall that the +host system of the library will be the target of the overall build. If +the overall build is a native build, the `--with-cross-host' option +will not be used. + + A library which can be built both standalone and as a target library +may want to install itself into different directories depending upon the +case. When built standalone, or when built native, the library should +be installed in `$(libdir)'. When built as a target library which is +not native, the library should be installed in `$(tooldir)/lib'. The +`--with-cross-host' option may be used to distinguish these cases. + + This same test of `--with-cross-host' may be used to see whether it +is OK to use link tests in the configure script. If the +`--with-cross-host' option is not used, then the library is being built +either standalone or native, and a link should work. + + +File: configure.info, Node: Make Targets in Cygnus Tree, Next: Target libiberty, Prev: Target Library Configure Scripts, Up: Cross Tools in the Cygnus Tree + +Make Targets in Cygnus Tree +--------------------------- + +The top level `Makefile' in the Cygnus tree defines targets for every +known subdirectory. + + For every subdirectory DIR which holds a host library or program, +the `Makefile' target `all-DIR' will build that library or program. + + There are dependencies among host tools. For example, building gcc +requires first building gas, because the gcc build process invokes the +target assembler. These dependencies are reflected in the top level +`Makefile'. + + For every subdirectory DIR which holds a target library, the +`Makefile' target `configure-target-DIR' will configure that library. +The `Makefile' target `all-target-DIR' will build that library. + + Every `configure-target-DIR' target depends upon `all-gcc', since +gcc, the target compiler, is required to configure the tool. Every +`all-target-DIR' target depends upon the corresponding +`configure-target-DIR' target. + + There are several other targets which may be of interest for each +directory: `install-DIR', `clean-DIR', and `check-DIR'. There are also +corresponding `target' versions of these for the target libraries , +such as `install-target-DIR'. + + +File: configure.info, Node: Target libiberty, Prev: Make Targets in Cygnus Tree, Up: Cross Tools in the Cygnus Tree + +Target libiberty +---------------- + +The `libiberty' subdirectory is currently a special case, in that it is +the only directory which is built both using the host compiler and +using the target compiler. + + This is because the files in `libiberty' are used when building the +host tools, and they are also incorporated into the `libstdc++' target +library as support code. + + This duality does not pose any particular difficulties. It means +that there are targets for both `all-libiberty' and +`all-target-libiberty'. + + In a native configuration, when target libraries are not built in a +subdirectory, the same objects are normally used as both the host build +and the target build. This is normally OK, since libiberty contains +only C code, and in a native configuration the results of the host +compiler and the target compiler are normally interoperable. + + Irix 6 is again an exception here, since the SGI native compiler +defaults to using the `O32' ABI, and gcc defaults to using the `N32' +ABI. On Irix 6, the target libraries are built in a subdirectory even +for a native configuration, avoiding this problem. + + There are currently no other libraries built for both the host and +the target, but there is no conceptual problem with adding more. + + +File: configure.info, Node: Canadian Cross, Next: Cygnus Configure, Prev: Cross Compilation Tools, Up: Top + +Canadian Cross +************** + +It is possible to use the GNU configure and build system to build a +program which will run on a system which is different from the system on +which the tools are built. In other words, it is possible to build +programs using a cross compiler. + + This is referred to as a "Canadian Cross". + +* Menu: + +* Canadian Cross Example:: Canadian Cross Example. +* Canadian Cross Concepts:: Canadian Cross Concepts. +* Build Cross Host Tools:: Build Cross Host Tools. +* Build and Host Options:: Build and Host Options. +* CCross not in Cygnus Tree:: Canadian Cross not in Cygnus Tree. +* CCross in Cygnus Tree:: Canadian Cross in Cygnus Tree. +* Supporting Canadian Cross:: Supporting Canadian Cross. + + +File: configure.info, Node: Canadian Cross Example, Next: Canadian Cross Concepts, Up: Canadian Cross + +Canadian Cross Example +====================== + +Here is an example of a Canadian Cross. + + While running on a GNU/Linux, you can build a program which will run +on a Solaris system. You would use a GNU/Linux cross Solaris compiler +to build the program. + + Of course, you could not run the resulting program on your GNU/Linux +system. You would have to copy it over to a Solaris system before you +would run it. + + Of course, you could also simply build the programs on the Solaris +system in the first place. However, perhaps the Solaris system is not +available for some reason; perhaps you actually don't have one, but you +want to build the tools for somebody else to use. Or perhaps your +GNU/Linux system is much faster than your Solaris system. + + A Canadian Cross build is most frequently used when building +programs to run on a non-Unix system, such as DOS or Windows. It may +be simpler to configure and build on a Unix system than to support the +configuration machinery on a non-Unix system. + + +File: configure.info, Node: Canadian Cross Concepts, Next: Build Cross Host Tools, Prev: Canadian Cross Example, Up: Canadian Cross + +Canadian Cross Concepts +======================= + +When building a Canadian Cross, there are at least two different systems +involved: the system on which the tools are being built, and the system +on which the tools will run. + + The system on which the tools are being built is called the "build" +system. + + The system on which the tools will run is called the host system. + + For example, if you are building a Solaris program on a GNU/Linux +system, as in the previous section, the build system would be GNU/Linux, +and the host system would be Solaris. + + It is, of course, possible to build a cross compiler using a Canadian +Cross (i.e., build a cross compiler using a cross compiler). In this +case, the system for which the resulting cross compiler generates code +is called the target system. (For a more complete discussion of host +and target systems, *note Host and Target::). + + An example of building a cross compiler using a Canadian Cross would +be building a Windows cross MIPS ELF compiler on a GNU/Linux system. In +this case the build system would be GNU/Linux, the host system would be +Windows, and the target system would be MIPS ELF. + + The name Canadian Cross comes from the case when the build, host, and +target systems are all different. At the time that these issues were +all being hashed out, Canada had three national political parties. + + +File: configure.info, Node: Build Cross Host Tools, Next: Build and Host Options, Prev: Canadian Cross Concepts, Up: Canadian Cross + +Build Cross Host Tools +====================== + +In order to configure a program for a Canadian Cross build, you must +first build and install the set of cross tools you will use to build the +program. + + These tools will be build cross host tools. That is, they will run +on the build system, and will produce code that runs on the host system. + + It is easy to confuse the meaning of build and host here. Always +remember that the build system is where you are doing the build, and the +host system is where the resulting program will run. Therefore, you +need a build cross host compiler. + + In general, you must have a complete cross environment in order to do +the build. This normally means a cross compiler, cross assembler, and +so forth, as well as libraries and include files for the host system. + + +File: configure.info, Node: Build and Host Options, Next: CCross not in Cygnus Tree, Prev: Build Cross Host Tools, Up: Canadian Cross + +Build and Host Options +====================== + +When you run `configure', you must use both the `--build' and `--host' +options. + + The `--build' option is used to specify the configuration name of +the build system. This can normally be the result of running the +`config.guess' shell script, and it is reasonable to use +`--build=`config.guess`'. + + The `--host' option is used to specify the configuration name of the +host system. + + As we explained earlier, `config.guess' is used to set the default +value for the `--host' option (*note Using the Host Type::). We can +now see that since `config.guess' returns the type of system on which +it is run, it really identifies the build system. Since the host +system is normally the same as the build system (i.e., people do not +normally build using a cross compiler), it is reasonable to use the +result of `config.guess' as the default for the host system when the +`--host' option is not used. + + It might seem that if the `--host' option were used without the +`--build' option that the configure script could run `config.guess' to +determine the build system, and presume a Canadian Cross if the result +of `config.guess' differed from the `--host' option. However, for +historical reasons, some configure scripts are routinely run using an +explicit `--host' option, rather than using the default from +`config.guess'. As noted earlier, it is difficult or impossible to +reliably compare configuration names (*note Using the Target Type::). +Therefore, by convention, if the `--host' option is used, but the +`--build' option is not used, then the build system defaults to the +host system. + + +File: configure.info, Node: CCross not in Cygnus Tree, Next: CCross in Cygnus Tree, Prev: Build and Host Options, Up: Canadian Cross + +Canadian Cross not in Cygnus Tree. +================================== + +If you are not using the Cygnus tree, you must explicitly specify the +cross tools which you want to use to build the program. This is done by +setting environment variables before running the `configure' script. + + You must normally set at least the environment variables `CC', `AR', +and `RANLIB' to the cross tools which you want to use to build. + + For some programs, you must set additional cross tools as well, such +as `AS', `LD', or `NM'. + + You would set these environment variables to the build cross tools +which you are going to use. + + For example, if you are building a Solaris program on a GNU/Linux +system, and your GNU/Linux cross Solaris compiler were named +`solaris-gcc', then you would set the environment variable `CC' to +`solaris-gcc'. + + +File: configure.info, Node: CCross in Cygnus Tree, Next: Supporting Canadian Cross, Prev: CCross not in Cygnus Tree, Up: Canadian Cross + +Canadian Cross in Cygnus Tree +============================= + +This section describes configuring and building a Canadian Cross when +using the Cygnus tree. + +* Menu: + +* Standard Cygnus CCross:: Building a Normal Program. +* Cross Cygnus CCross:: Building a Cross Program. + + +File: configure.info, Node: Standard Cygnus CCross, Next: Cross Cygnus CCross, Up: CCross in Cygnus Tree + +Building a Normal Program +------------------------- + +When configuring a Canadian Cross in the Cygnus tree, all the +appropriate environment variables are automatically set to `HOST-TOOL', +where HOST is the value used for the `--host' option, and TOOL is the +name of the tool (e.g., `gcc', `as', etc.). These tools must be on +your `PATH'. + + Adding a prefix of HOST will give the usual name for the build cross +host tools. To see this, consider that when these cross tools were +built, they were configured to run on the build system and to produce +code for the host system. That is, they were configured with a +`--target' option that is the same as the system which we are now +calling the host. Recall that the default name for installed cross +tools uses the target system as a prefix (*note Using the Target +Type::). Since that is the system which we are now calling the host, +HOST is the right prefix to use. + + For example, if you configure with `--build=i386-linux-gnu' and +`--host=solaris', then the Cygnus tree will automatically default to +using the compiler `solaris-gcc'. You must have previously built and +installed this compiler, probably by doing a build with no `--host' +option and with a `--target' option of `solaris'. + + +File: configure.info, Node: Cross Cygnus CCross, Prev: Standard Cygnus CCross, Up: CCross in Cygnus Tree + +Building a Cross Program +------------------------ + +There are additional considerations if you want to build a cross +compiler, rather than a native compiler, in the Cygnus tree using a +Canadian Cross. + + When you build a cross compiler using the Cygnus tree, then the +target libraries will normally be built with the newly built target +compiler (*note Host and Target Libraries::). However, this will not +work when building with a Canadian Cross. This is because the newly +built target compiler will be a program which runs on the host system, +and therefore will not be able to run on the build system. + + Therefore, when building a cross compiler with the Cygnus tree, you +must first install a set of build cross target tools. These tools will +be used when building the target libraries. + + Note that this is not a requirement of a Canadian Cross in general. +For example, it would be possible to build just the host cross target +tools on the build system, to copy the tools to the host system, and to +build the target libraries on the host system. The requirement for +build cross target tools is imposed by the Cygnus tree, which expects +to be able to build both host programs and target libraries in a single +`configure'/`make' step. Because it builds these in a single step, it +expects to be able to build the target libraries on the build system, +which means that it must use a build cross target toolchain. + + For example, suppose you want to build a Windows cross MIPS ELF +compiler on a GNU/Linux system. You must have previously installed +both a GNU/Linux cross Windows compiler and a GNU/Linux cross MIPS ELF +compiler. + + In order to build the Windows (configuration name `i386-cygwin32') +cross MIPS ELF (configure name `mips-elf') compiler, you might execute +the following commands (long command lines are broken across lines with +a trailing backslash as a continuation character). + + mkdir linux-x-cygwin32 + cd linux-x-cygwin32 + SRCDIR/configure --target i386-cygwin32 --prefix=INSTALLDIR \ + --exec-prefix=INSTALLDIR/H-i386-linux + make + make install + cd .. + mkdir linux-x-mips-elf + cd linux-x-mips-elf + SRCDIR/configure --target mips-elf --prefix=INSTALLDIR \ + --exec-prefix=INSTALLDIR/H-i386-linux + make + make install + cd .. + mkdir cygwin32-x-mips-elf + cd cygwin32-x-mips-elf + SRCDIR/configure --build=i386-linux-gnu --host=i386-cygwin32 \ + --target=mips-elf --prefix=WININSTALLDIR \ + --exec-prefix=WININSTALLDIR/H-i386-cygwin32 + make + make install + + You would then copy the contents of WININSTALLDIR over to the +Windows machine, and run the resulting programs. + + +File: configure.info, Node: Supporting Canadian Cross, Prev: CCross in Cygnus Tree, Up: Canadian Cross + +Supporting Canadian Cross +========================= + +If you want to make it possible to build a program you are developing +using a Canadian Cross, you must take some care when writing your +configure and make rules. Simple cases will normally work correctly. +However, it is not hard to write configure and make tests which will +fail in a Canadian Cross. + +* Menu: + +* CCross in Configure:: Supporting Canadian Cross in Configure Scripts. +* CCross in Make:: Supporting Canadian Cross in Makefiles. + + +File: configure.info, Node: CCross in Configure, Next: CCross in Make, Up: Supporting Canadian Cross + +Supporting Canadian Cross in Configure Scripts +---------------------------------------------- + +In a `configure.in' file, after calling `AC_PROG_CC', you can find out +whether this is a Canadian Cross configure by examining the shell +variable `cross_compiling'. In a Canadian Cross, which means that the +compiler is a cross compiler, `cross_compiling' will be `yes'. In a +normal configuration, `cross_compiling' will be `no'. + + You ordinarily do not need to know the type of the build system in a +configure script. However, if you do need that information, you can get +it by using the macro `AC_CANONICAL_SYSTEM', the same macro that is +used to determine the target system. This macro will set the variables +`build', `build_alias', `build_cpu', `build_vendor', and `build_os', +which correspond to the similar `target' and `host' variables, except +that they describe the build system. + + When writing tests in `configure.in', you must remember that you +want to test the host environment, not the build environment. + + Macros like `AC_CHECK_FUNCS' which use the compiler will test the +host environment. That is because the tests will be done by running the +compiler, which is actually a build cross host compiler. If the +compiler can find the function, that means that the function is present +in the host environment. + + Tests like `test -f /dev/ptyp0', on the other hand, will test the +build environment. Remember that the configure script is running on the +build system, not the host system. If your configure scripts examines +files, those files will be on the build system. Whatever you determine +based on those files may or may not be the case on the host system. + + Most autoconf macros will work correctly for a Canadian Cross. The +main exception is `AC_TRY_RUN'. This macro tries to compile and run a +test program. This will fail in a Canadian Cross, because the program +will be compiled for the host system, which means that it will not run +on the build system. + + The `AC_TRY_RUN' macro provides an optional argument to tell the +configure script what to do in a Canadian Cross. If that argument is +not present, you will get a warning when you run `autoconf': + warning: AC_TRY_RUN called without default to allow cross compiling + +This tells you that the resulting `configure' script will not work with +a Canadian Cross. + + In some cases while it may better to perform a test at configure +time, it is also possible to perform the test at run time. In such a +case you can use the cross compiling argument to `AC_TRY_RUN' to tell +your program that the test could not be performed at configure time. + + There are a few other autoconf macros which will not work correctly +with a Canadian Cross: a partial list is `AC_FUNC_GETPGRP', +`AC_FUNC_SETPGRP', `AC_FUNC_SETVBUF_REVERSED', and +`AC_SYS_RESTARTABLE_SYSCALLS'. The `AC_CHECK_SIZEOF' macro is +generally not very useful with a Canadian Cross; it permits an optional +argument indicating the default size, but there is no way to know what +the correct default should be. + + +File: configure.info, Node: CCross in Make, Prev: CCross in Configure, Up: Supporting Canadian Cross + +Supporting Canadian Cross in Makefiles. +--------------------------------------- + +The main Canadian Cross issue in a `Makefile' arises when you want to +use a subsidiary program to generate code or data which you will then +include in your real program. + + If you compile this subsidiary program using `$(CC)' in the usual +way, you will not be able to run it. This is because `$(CC)' will +build a program for the host system, but the program is being built on +the build system. + + You must instead use a compiler for the build system, rather than the +host system. In the Cygnus tree, this make variable `$(CC_FOR_BUILD)' +will hold a compiler for the build system. + + Note that you should not include `config.h' in a file you are +compiling with `$(CC_FOR_BUILD)'. The `configure' script will build +`config.h' with information for the host system. However, you are +compiling the file using a compiler for the build system (a native +compiler). Subsidiary programs are normally simple filters which do no +user interaction, and it is normally possible to write them in a highly +portable fashion so that the absence of `config.h' is not crucial. + + The gcc `Makefile.in' shows a complex situation in which certain +files, such as `rtl.c', must be compiled into both subsidiary programs +run on the build system and into the final program. This approach may +be of interest for advanced build system hackers. Note that the build +system compiler is rather confusingly called `HOST_CC'. + + +File: configure.info, Node: Cygnus Configure, Next: Multilibs, Prev: Canadian Cross, Up: Top + +Cygnus Configure +**************** + +The Cygnus configure script predates autoconf. All of its interesting +features have been incorporated into autoconf. No new programs should +be written to use the Cygnus configure script. + + However, the Cygnus configure script is still used in a few places: +at the top of the Cygnus tree and in a few target libraries in the +Cygnus tree. Until those uses have been replaced with autoconf, some +brief notes are appropriate here. This is not complete documentation, +but it should be possible to use this as a guide while examining the +scripts themselves. + +* Menu: + +* Cygnus Configure Basics:: Cygnus Configure Basics. +* Cygnus Configure in C++ Libraries:: Cygnus Configure in C++ Libraries. + + +File: configure.info, Node: Cygnus Configure Basics, Next: Cygnus Configure in C++ Libraries, Up: Cygnus Configure + +Cygnus Configure Basics +======================= + +Cygnus configure does not use any generated files; there is no program +corresponding to `autoconf'. Instead, there is a single shell script +named `configure' which may be found at the top of the Cygnus tree. +This shell script was written by hand; it was not generated by +autoconf, and it is incorrect, and indeed harmful, to run `autoconf' in +the top level of a Cygnus tree. + + Cygnus configure works in a particular directory by examining the +file `configure.in' in that directory. That file is broken into four +separate shell scripts. + + The first is the contents of `configure.in' up to a line that starts +with `# per-host:'. This is the common part. + + The second is the rest of `configure.in' up to a line that starts +with `# per-target:'. This is the per host part. + + The third is the rest of `configure.in' up to a line that starts +with `# post-target:'. This is the per target part. + + The fourth is the remainder of `configure.in'. This is the post +target part. + + If any of these comment lines are missing, the corresponding shell +script is empty. + + Cygnus configure will first execute the common part. This must set +the shell variable `srctrigger' to the name of a source file, to +confirm that Cygnus configure is looking at the right directory. This +may set the shell variables `package_makefile_frag' and +`package_makefile_rules_frag'. + + Cygnus configure will next set the `build' and `host' shell +variables, and execute the per host part. This may set the shell +variable `host_makefile_frag'. + + Cygnus configure will next set the `target' variable, and execute +the per target part. This may set the shell variable +`target_makefile_frag'. + + Any of these scripts may set the `subdirs' shell variable. This +variable is a list of subdirectories where a `Makefile.in' file may be +found. Cygnus configure will automatically look for a `Makefile.in' +file in the current directory. The `subdirs' shell variable is not +normally used, and I believe that the only directory which uses it at +present is `newlib'. + + For each `Makefile.in', Cygnus configure will automatically create a +`Makefile' by adding definitions for `make' variables such as `host' +and `target', and automatically editing the values of `make' variables +such as `prefix' if they are present. + + Also, if any of the `makefile_frag' shell variables are set, Cygnus +configure will interpret them as file names relative to either the +working directory or the source directory, and will read the contents of +the file into the generated `Makefile'. The file contents will be read +in after the first line in `Makefile.in' which starts with `####'. + + These `Makefile' fragments are used to customize behaviour for a +particular host or target. They serve to select particular files to +compile, and to define particular preprocessor macros by providing +values for `make' variables which are then used during compilation. +Cygnus configure, unlike autoconf, normally does not do feature tests, +and normally requires support to be added manually for each new host. + + The `Makefile' fragment support is similar to the autoconf +`AC_SUBST_FILE' macro. + + After creating each `Makefile', the post target script will be run +(i.e., it may be run several times). This script may further customize +the `Makefile'. When it is run, the shell variable `Makefile' will +hold the name of the `Makefile', including the appropriate directory +component. + + Like an autoconf generated `configure' script, Cygnus configure will +create a file named `config.status' which, when run, will automatically +recreate the configuration. The `config.status' file will simply +execute the Cygnus configure script again with the appropriate +arguments. + + Any of the parts of `configure.in' may set the shell variables +`files' and `links'. Cygnus configure will set up symlinks from the +names in `links' to the files named in `files'. This is similar to the +autoconf `AC_LINK_FILES' macro. + + Finally, any of the parts of `configure.in' may set the shell +variable `configdirs' to a set of subdirectories. If it is set, Cygnus +configure will recursively run the configure process in each +subdirectory. If the subdirectory uses Cygnus configure, it will +contain a `configure.in' file but no `configure' file, in which case +Cygnus configure will invoke itself recursively. If the subdirectory +has a `configure' file, Cygnus configure assumes that it is an autoconf +generated `configure' script, and simply invokes it directly. + + +File: configure.info, Node: Cygnus Configure in C++ Libraries, Prev: Cygnus Configure Basics, Up: Cygnus Configure + +Cygnus Configure in C++ Libraries +================================= + +The C++ library configure system, written by Per Bothner, deserves +special mention. It uses Cygnus configure, but it does feature testing +like that done by autoconf generated `configure' scripts. This +approach is used in the libraries `libio', `libstdc++', and `libg++'. + + Most of the `Makefile' information is written out by the shell +script `libio/config.shared'. Each `configure.in' file sets certain +shell variables, and then invokes `config.shared' to create two package +`Makefile' fragments. These fragments are then incorporated into the +resulting `Makefile' by the Cygnus configure script. + + The file `_G_config.h' is created in the `libio' object directory by +running the shell script `libio/gen-params'. This shell script uses +feature tests to define macros and typedefs in `_G_config.h'. + + +File: configure.info, Node: Multilibs, Next: FAQ, Prev: Cygnus Configure, Up: Top + +Multilibs +********* + +For some targets gcc may have different processor requirements depending +upon command line options. An obvious example is the `-msoft-float' +option supported on several processors. This option means that the +floating point registers are not available, which means that floating +point operations must be done by calling an emulation subroutine rather +than by using machine instructions. + + For such options, gcc is often configured to compile target libraries +twice: once with `-msoft-float' and once without. When gcc compiles +target libraries more than once, the resulting libraries are called +"multilibs". + + Multilibs are not really part of the GNU configure and build system, +but we discuss them here since they require support in the `configure' +scripts and `Makefile's used for target libraries. + +* Menu: + +* Multilibs in gcc:: Multilibs in gcc. +* Multilibs in Target Libraries:: Multilibs in Target Libraries. + + +File: configure.info, Node: Multilibs in gcc, Next: Multilibs in Target Libraries, Up: Multilibs + +Multilibs in gcc +================ + +In gcc, multilibs are defined by setting the variable +`MULTILIB_OPTIONS' in the target `Makefile' fragment. Several other +`MULTILIB' variables may also be defined there. *Note The Target +Makefile Fragment: (gcc)Target Fragment. + + If you have built gcc, you can see what multilibs it uses by running +it with the `-print-multi-lib' option. The output `.;' means that no +multilibs are used. In general, the output is a sequence of lines, one +per multilib. The first part of each line, up to the `;', is the name +of the multilib directory. The second part is a list of compiler +options separated by `@' characters. + + Multilibs are built in a tree of directories. The top of the tree, +represented by `.' in the list of multilib directories, is the default +library to use when no special compiler options are used. The +subdirectories of the tree hold versions of the library to use when +particular compiler options are used. + + +File: configure.info, Node: Multilibs in Target Libraries, Prev: Multilibs in gcc, Up: Multilibs + +Multilibs in Target Libraries +============================= + +The target libraries in the Cygnus tree are automatically built with +multilibs. That means that each library is built multiple times. + + This default is set in the top level `configure.in' file, by adding +`--enable-multilib' to the list of arguments passed to configure when +it is run for the target libraries (*note Host and Target Libraries::). + + Each target library uses the shell script `config-ml.in', written by +Doug Evans, to prepare to build target libraries. This shell script is +invoked after the `Makefile' has been created by the `configure' +script. If multilibs are not enabled, it does nothing, otherwise it +modifies the `Makefile' to support multilibs. + + The `config-ml.in' script makes one copy of the `Makefile' for each +multilib in the appropriate subdirectory. When configuring in the +source directory (which is not recommended), it will build a symlink +tree of the sources in each subdirectory. + + The `config-ml.in' script sets several variables in the various +`Makefile's. The `Makefile.in' must have definitions for these +variables already; `config-ml.in' simply changes the existing values. +The `Makefile' should use default values for these variables which will +do the right thing in the subdirectories. + +`MULTISRCTOP' + `config-ml.in' will set this to a sequence of `../' strings, where + the number of strings is the number of multilib levels in the + source tree. The default value should be the empty string. + +`MULTIBUILDTOP' + `config-ml.in' will set this to a sequence of `../' strings, where + the number of strings is number of multilib levels in the object + directory. The default value should be the empty string. This + will differ from `MULTISRCTOP' when configuring in the source tree + (which is not recommended). + +`MULTIDIRS' + In the top level `Makefile' only, `config-ml.in' will set this to + the list of multilib subdirectories. The default value should be + the empty string. + +`MULTISUBDIR' + `config-ml.in' will set this to the installed subdirectory name to + use for this subdirectory, with a leading `/'. The default value + shold be the empty string. + +`MULTIDO' +`MULTICLEAN' + In the top level `Makefile' only, `config-ml.in' will set these + variables to commands to use when doing a recursive make. These + variables should both default to the string `true', so that by + default nothing happens. + + All references to the parent of the source directory should use the +variable `MULTISRCTOP'. Instead of writing `$(srcdir)/..', you must +write `$(srcdir)/$(MULTISRCTOP)..'. + + Similarly, references to the parent of the object directory should +use the variable `MULTIBUILDTOP'. + + In the installation target, the libraries should be installed in the +subdirectory `MULTISUBDIR'. Instead of installing +`$(libdir)/libfoo.a', install `$(libdir)$(MULTISUBDIR)/libfoo.a'. + + The `config-ml.in' script also modifies the top level `Makefile' to +add `multi-do' and `multi-clean' targets which are used when building +multilibs. + + The default target of the `Makefile' should include the following +command: + @$(MULTIDO) $(FLAGS_TO_PASS) DO=all multi-do + +This assumes that `$(FLAGS_TO_PASS)' is defined as a set of variables +to pass to a recursive invocation of `make'. This will build all the +multilibs. Note that the default value of `MULTIDO' is `true', so by +default this command will do nothing. It will only do something in the +top level `Makefile' if multilibs were enabled. + + The `install' target of the `Makefile' should include the following +command: + @$(MULTIDO) $(FLAGS_TO_PASS) DO=install multi-do + + In general, any operation, other than clean, which should be +performed on all the multilibs should use a `$(MULTIDO)' line, setting +the variable `DO' to the target of each recursive call to `make'. + + The `clean' targets (`clean', `mostlyclean', etc.) should use +`$(MULTICLEAN)'. For example, the `clean' target should do this: + @$(MULTICLEAN) DO=clean multi-clean + + +File: configure.info, Node: FAQ, Next: Index, Prev: Multilibs, Up: Top + +Frequently Asked Questions +************************** + +Which do I run first, `autoconf' or `automake'? + Except when you first add autoconf or automake support to a + package, you shouldn't run either by hand. Instead, configure + with the `--enable-maintainer-mode' option, and let `make' take + care of it. + +`autoconf' says something about undefined macros. + This means that you have macros in your `configure.in' which are + not defined by `autoconf'. You may be using an old version of + `autoconf'; try building and installing a newer one. Make sure the + newly installled `autoconf' is first on your `PATH'. Also, see + the next question. + +My `configure' script has stuff like `CY_GNU_GETTEXT' in it. + This means that you have macros in your `configure.in' which should + be defined in your `aclocal.m4' file, but aren't. This usually + means that `aclocal' was not able to appropriate definitions of the + macros. Make sure that you have installed all the packages you + need. In particular, make sure that you have installed libtool + (this is where `AM_PROG_LIBTOOL' is defined) and gettext (this is + where `CY_GNU_GETTEXT' is defined, at least in the Cygnus version + of gettext). + +My `Makefile' has `@' characters in it. + This may mean that you tried to use an autoconf substitution in + your `Makefile.in' without adding the appropriate `AC_SUBST' call + to your `configure' script. Or it may just mean that you need to + rebuild `Makefile' in your build directory. To rebuild `Makefile' + from `Makefile.in', run the shell script `config.status' with no + arguments. If you need to force `configure' to run again, first + run `config.status --recheck'. These runs are normally done + automatically by `Makefile' targets, but if your `Makefile' has + gotten messed up you'll need to help them along. + +Why do I have to run both `config.status --recheck' and `config.status'? + Normally, you don't; they will be run automatically by `Makefile' + targets. If you do need to run them, use `config.status --recheck' + to run the `configure' script again with the same arguments as the + first time you ran it. Use `config.status' (with no arguments) to + regenerate all files (`Makefile', `config.h', etc.) based on the + results of the configure script. The two cases are separate + because it isn't always necessary to regenerate all the files + after running `config.status --recheck'. The `Makefile' targets + generated by automake will use the environment variables + `CONFIG_FILES' and `CONFIG_HEADERS' to only regenerate files as + they are needed. + +What is the Cygnus tree? + The Cygnus tree is used for various packages including gdb, the GNU + binutils, and egcs. It is also, of course, used for Cygnus + releases. It is the build system which was developed at Cygnus, + using the Cygnus configure script. It permits building many + different packages with a single configure and make. The + configure scripts in the tree are being converted to autoconf, but + the general build structure remains intact. + +Why do I have to keep rebuilding and reinstalling the tools? + I know, it's a pain. Unfortunately, there are bugs in the tools + themselves which need to be fixed, and each time that happens + everybody who uses the tools need to reinstall new versions of + them. I don't know if there is going to be a clever fix until the + tools stabilize. + +Why not just have a Cygnus tree `make' target to update the tools? + The tools unfortunately need to be installed before they can be + used. That means that they must be built using an appropriate + prefix, and it seems unwise to assume that every configuration + uses an appropriate prefix. It might be possible to make them + work in place, or it might be possible to install them in some + subdirectory; so far these approaches have not been implemented. + + +File: configure.info, Node: Index, Prev: FAQ, Up: Top + +Index +***** + +* Menu: + +* --build option: Build and Host Options. +* --host option: Build and Host Options. +* --target option: Specifying the Target. +* _GNU_SOURCE: Write configure.in. +* AC_CANONICAL_HOST: Using the Host Type. +* AC_CANONICAL_SYSTEM: Using the Target Type. +* AC_CONFIG_HEADER: Write configure.in. +* AC_EXEEXT: Write configure.in. +* AC_INIT: Write configure.in. +* AC_OUTPUT: Write configure.in. +* AC_PREREQ: Write configure.in. +* AC_PROG_CC: Write configure.in. +* AC_PROG_CXX: Write configure.in. +* acconfig.h: Written Developer Files. +* acconfig.h, writing: Write acconfig.h. +* acinclude.m4: Written Developer Files. +* aclocal.m4: Generated Developer Files. +* AM_CONFIG_HEADER: Write configure.in. +* AM_DISABLE_SHARED: Write configure.in. +* AM_EXEEXT: Write configure.in. +* AM_INIT_AUTOMAKE: Write configure.in. +* AM_MAINTAINER_MODE: Write configure.in. +* AM_PROG_LIBTOOL: Write configure.in. +* AM_PROG_LIBTOOL in configure: FAQ. +* build option: Build and Host Options. +* building with a cross compiler: Canadian Cross. +* canadian cross: Canadian Cross. +* canadian cross in configure: CCross in Configure. +* canadian cross in cygnus tree: CCross in Cygnus Tree. +* canadian cross in makefile: CCross in Make. +* canadian cross, configuring: Build and Host Options. +* canonical system names: Configuration Names. +* config.cache: Build Files Description. +* config.h: Build Files Description. +* config.h.in: Generated Developer Files. +* config.in: Generated Developer Files. +* config.status: Build Files Description. +* config.status --recheck: FAQ. +* configuration names: Configuration Names. +* configuration triplets: Configuration Names. +* configure: Generated Developer Files. +* configure build system: Build and Host Options. +* configure host: Build and Host Options. +* configure target: Specifying the Target. +* configure.in: Written Developer Files. +* configure.in, writing: Write configure.in. +* configuring a canadian cross: Build and Host Options. +* cross compiler: Cross Compilation Concepts. +* cross compiler, building with: Canadian Cross. +* cross tools: Cross Compilation Tools. +* CY_GNU_GETTEXT in configure: FAQ. +* cygnus configure: Cygnus Configure. +* goals: Goals. +* history: History. +* host names: Configuration Names. +* host option: Build and Host Options. +* host system: Host and Target. +* host triplets: Configuration Names. +* HOST_CC: CCross in Make. +* libg++ configure: Cygnus Configure in C++ Libraries. +* libio configure: Cygnus Configure in C++ Libraries. +* libstdc++ configure: Cygnus Configure in C++ Libraries. +* Makefile: Build Files Description. +* Makefile, garbage characters: FAQ. +* Makefile.am: Written Developer Files. +* Makefile.am, writing: Write Makefile.am. +* Makefile.in: Generated Developer Files. +* multilibs: Multilibs. +* stamp-h: Build Files Description. +* stamp-h.in: Generated Developer Files. +* system names: Configuration Names. +* system types: Configuration Names. +* target option: Specifying the Target. +* target system: Host and Target. +* triplets: Configuration Names. +* undefined macros: FAQ. + + Tag Table: -(Indirect) Node: Top971 -Node: Introduction1502 -Node: Goals2583 -Node: Tools3302 -Node: History4291 -Node: Building7284 -Node: Getting Started10374 -Node: Write configure.in10886 -Node: Write Makefile.am18132 -Node: Write acconfig.h21290 -Node: Generate files22827 -Node: Getting Started Example24788 -Node: Getting Started Example 125538 -Node: Getting Started Example 227475 -Node: Getting Started Example 330591 -Node: Generate Files in Example32961 -Node: Files34042 -Node: Developer Files34653 -Node: Developer Files Picture35028 -Node: Written Developer Files36320 -Node: Generated Developer Files38863 -Node: Build Files41998 -Node: Build Files Picture42654 -Node: Build Files Description43409 -Node: Support Files45406 -Node: Configuration Names48283 -Node: Configuration Name Definition48782 -Node: Using Configuration Names51100 -Node: Cross Compilation Tools53067 -Node: Cross Compilation Concepts53757 -Node: Host and Target54719 -Node: Using the Host Type56215 -Node: Specifying the Target57559 -Node: Using the Target Type58343 -Node: Cross Tools in the Cygnus Tree61769 -Node: Host and Target Libraries62821 -Node: Target Library Configure Scripts66561 -Node: Make Targets in Cygnus Tree69644 -Node: Target libiberty70983 -Node: Canadian Cross72361 -Node: Canadian Cross Example73201 -Node: Canadian Cross Concepts74315 -Node: Build Cross Host Tools75822 -Node: Build and Host Options76769 -Node: CCross not in Cygnus Tree78550 -Node: CCross in Cygnus Tree79523 -Node: Standard Cygnus CCross79939 -Node: Cross Cygnus CCross81294 -Node: Supporting Canadian Cross84085 -Node: CCross in Configure84695 -Node: CCross in Make87852 -Node: Cygnus Configure89446 -Node: Cygnus Configure Basics90280 -Node: Cygnus Configure in C++ Libraries94954 -Node: Multilibs95956 -Node: Multilibs in gcc97000 -Node: Multilibs in Target Libraries98073 -Node: FAQ102257 -Node: Index106353 +Node: Introduction1499 +Node: Goals2577 +Node: Tools3293 +Node: History4279 +Node: Building7269 +Node: Getting Started10356 +Node: Write configure.in10865 +Node: Write Makefile.am18108 +Node: Write acconfig.h21263 +Node: Generate files22797 +Node: Getting Started Example24755 +Node: Getting Started Example 125502 +Node: Getting Started Example 227436 +Node: Getting Started Example 330549 +Node: Generate Files in Example32916 +Node: Files33994 +Node: Developer Files34601 +Node: Developer Files Picture34973 +Node: Written Developer Files36282 +Node: Generated Developer Files38822 +Node: Build Files41954 +Node: Build Files Picture42607 +Node: Build Files Description43379 +Node: Support Files45373 +Node: Configuration Names48247 +Node: Configuration Name Definition48743 +Node: Using Configuration Names51058 +Node: Cross Compilation Tools53020 +Node: Cross Compilation Concepts53707 +Node: Host and Target54667 +Node: Using the Host Type56160 +Node: Specifying the Target57501 +Node: Using the Target Type58282 +Node: Cross Tools in the Cygnus Tree61705 +Node: Host and Target Libraries62754 +Node: Target Library Configure Scripts66491 +Node: Make Targets in Cygnus Tree69571 +Node: Target libiberty70907 +Node: Canadian Cross72282 +Node: Canadian Cross Example73119 +Node: Canadian Cross Concepts74230 +Node: Build Cross Host Tools75734 +Node: Build and Host Options76678 +Node: CCross not in Cygnus Tree78456 +Node: CCross in Cygnus Tree79426 +Node: Standard Cygnus CCross79839 +Node: Cross Cygnus CCross81191 +Node: Supporting Canadian Cross83979 +Node: CCross in Configure84586 +Node: CCross in Make87740 +Node: Cygnus Configure89331 +Node: Cygnus Configure Basics90162 +Node: Cygnus Configure in C++ Libraries94832 +Node: Multilibs95831 +Node: Multilibs in gcc96872 +Node: Multilibs in Target Libraries97942 +Node: FAQ102123 +Node: Index106219 End Tag Table diff --git a/gnu/dist/binutils/etc/standards.info b/gnu/dist/binutils/etc/standards.info index 2eb32a8c9af..0c5be291ace 100644 --- a/gnu/dist/binutils/etc/standards.info +++ b/gnu/dist/binutils/etc/standards.info @@ -1,4 +1,4 @@ -This is standards.info, produced by makeinfo version 4.3 from +This is standards.info, produced by makeinfo version 4.6 from ./standards.texi. START-INFO-DIR-ENTRY @@ -21,7 +21,7 @@ File: standards.info, Node: Top, Next: Preface, Prev: (dir), Up: (dir) Version ******* - Last updated February 14, 2002. +Last updated February 14, 2002. * Menu: @@ -42,8 +42,8 @@ File: standards.info, Node: Preface, Next: Legal Issues, Prev: Top, Up: Top About the GNU Coding Standards ****************************** - The GNU Coding Standards were written by Richard Stallman and other -GNU Project volunteers. Their purpose is to make the GNU system clean, +The GNU Coding Standards were written by Richard Stallman and other GNU +Project volunteers. Their purpose is to make the GNU system clean, consistent, and easy to install. This document can also be read as a guide to writing portable, robust and reliable programs. It focuses on programs written in C, but many of the rules and principles are useful @@ -87,7 +87,7 @@ File: standards.info, Node: Legal Issues, Next: Design Advice, Prev: Preface, Keeping Free Software Free ************************** - This node discusses how you can make sure that GNU software avoids +This node discusses how you can make sure that GNU software avoids legal difficulties, and other related issues. * Menu: @@ -102,8 +102,8 @@ File: standards.info, Node: Reading Non-Free Code, Next: Contributions, Up: L Referring to Proprietary Programs ================================= - Don't in any circumstances refer to Unix source code for or during -your work on GNU! (Or to any other proprietary programs.) +Don't in any circumstances refer to Unix source code for or during your +work on GNU! (Or to any other proprietary programs.) If you have a vague recollection of the internals of a Unix program, this does not absolutely mean you can't write an imitation of it, but @@ -139,7 +139,7 @@ File: standards.info, Node: Contributions, Next: Trademarks, Prev: Reading No Accepting Contributions ======================= - If the program you are working on is copyrighted by the Free Software +If the program you are working on is copyrighted by the Free Software Foundation, then when someone else sends you a piece of code to add to the program, we need legal papers to use it--just as we asked you to sign papers initially. _Each_ person who makes a nontrivial @@ -186,7 +186,7 @@ File: standards.info, Node: Trademarks, Prev: Contributions, Up: Legal Issues Trademarks ========== - Please do not include any trademark acknowledgements in GNU software +Please do not include any trademark acknowledgements in GNU software packages or documentation. Trademark acknowledgements are the statements that such-and-such is a @@ -210,7 +210,7 @@ File: standards.info, Node: Design Advice, Next: Program Behavior, Prev: Lega General Program Design ********************** - This node discusses some of the issues you should take into account +This node discusses some of the issues you should take into account when designing your program. * Menu: @@ -227,7 +227,7 @@ File: standards.info, Node: Source Language, Next: Compatibility, Up: Design Which Languages to Use ====================== - When you want to use a language that gets compiled and runs at high +When you want to use a language that gets compiled and runs at high speed, the best language to use is C. Using another language is like using a non-standard feature: it will cause trouble for users. Even if GCC supports the other language, users may find it inconvenient to have @@ -272,7 +272,7 @@ File: standards.info, Node: Compatibility, Next: Using Extensions, Prev: Sour Compatibility with Other Implementations ======================================== - With occasional exceptions, utility programs and libraries for GNU +With occasional exceptions, utility programs and libraries for GNU should be upward compatible with those in Berkeley Unix, and upward compatible with Standard C if Standard C specifies their behavior, and upward compatible with POSIX if POSIX specifies their behavior. @@ -307,7 +307,7 @@ File: standards.info, Node: Using Extensions, Next: Standard C, Prev: Compati Using Non-standard Features =========================== - Many GNU facilities that already exist support a number of convenient +Many GNU facilities that already exist support a number of convenient extensions over the comparable Unix facilities. Whether to use these extensions in implementing your program is a difficult question. @@ -343,7 +343,7 @@ File: standards.info, Node: Standard C, Next: Conditional Compilation, Prev: Standard C and Pre-Standard C ============================= - 1989 Standard C is widespread enough now that it is ok to use its +1989 Standard C is widespread enough now that it is ok to use its features in new programs. There is one exception: do not ever use the "trigraph" feature of Standard C. @@ -407,10 +407,10 @@ File: standards.info, Node: Conditional Compilation, Prev: Standard C, Up: De Conditional Compilation ======================= - When supporting configuration options already known when building -your program we prefer using `if (... )' over conditional compilation, -as in the former case the compiler is able to perform more extensive -checking of all possible code paths. +When supporting configuration options already known when building your +program we prefer using `if (... )' over conditional compilation, as in +the former case the compiler is able to perform more extensive checking +of all possible code paths. For example, please write @@ -452,8 +452,8 @@ File: standards.info, Node: Program Behavior, Next: Writing C, Prev: Design A Program Behavior for All Programs ********************************* - This node describes conventions for writing robust software. It -also describes general standards for error messages, the command line +This node describes conventions for writing robust software. It also +describes general standards for error messages, the command line interface, and how libraries should behave. * Menu: @@ -474,11 +474,10 @@ File: standards.info, Node: Semantics, Next: Libraries, Up: Program Behavior Writing Robust Programs ======================= - Avoid arbitrary limits on the length or number of _any_ data -structure, including file names, lines, files, and symbols, by -allocating all data structures dynamically. In most Unix utilities, -"long lines are silently truncated". This is not acceptable in a GNU -utility. +Avoid arbitrary limits on the length or number of _any_ data structure, +including file names, lines, files, and symbols, by allocating all data +structures dynamically. In most Unix utilities, "long lines are +silently truncated". This is not acceptable in a GNU utility. Utilities reading files should not drop NUL characters, or any other nonprinting characters _including those with codes above 0177_. The @@ -573,7 +572,7 @@ File: standards.info, Node: Libraries, Next: Errors, Prev: Semantics, Up: Pr Library Behavior ================ - Try to make library functions reentrant. If they need to do dynamic +Try to make library functions reentrant. If they need to do dynamic storage allocation, at least try to avoid any nonreentrancy aside from that of `malloc' itself. @@ -604,7 +603,7 @@ File: standards.info, Node: Errors, Next: User Interfaces, Prev: Libraries, Formatting Error Messages ========================= - Error messages from compilers should look like this: +Error messages from compilers should look like this: SOURCE-FILE-NAME:LINENO: MESSAGE @@ -654,9 +653,9 @@ File: standards.info, Node: User Interfaces, Next: Graphical Interfaces, Prev Standards for Interfaces Generally ================================== - Please don't make the behavior of a utility depend on the name used -to invoke it. It is useful sometimes to make a link to a utility with -a different name, and that should not change what it does. +Please don't make the behavior of a utility depend on the name used to +invoke it. It is useful sometimes to make a link to a utility with a +different name, and that should not change what it does. Instead, use a run time option or a compilation switch or both to select among the alternate behaviors. @@ -688,7 +687,7 @@ File: standards.info, Node: Graphical Interfaces, Next: Command-Line Interface Standards for Graphical Interfaces ================================== - When you write a program that provides a graphical user interface, +When you write a program that provides a graphical user interface, please make it work with X Windows and the GTK toolkit unless the functionality specifically requires some alternative (for example, "displaying jpeg images while in console mode"). @@ -710,12 +709,11 @@ File: standards.info, Node: Command-Line Interfaces, Next: Option Table, Prev Standards for Command Line Interfaces ===================================== - It is a good idea to follow the POSIX guidelines for the -command-line options of a program. The easiest way to do this is to use -`getopt' to parse them. Note that the GNU version of `getopt' will -normally permit options anywhere among the arguments unless the special -argument `--' is used. This is not what POSIX specifies; it is a GNU -extension. +It is a good idea to follow the POSIX guidelines for the command-line +options of a program. The easiest way to do this is to use `getopt' to +parse them. Note that the GNU version of `getopt' will normally permit +options anywhere among the arguments unless the special argument `--' +is used. This is not what POSIX specifies; it is a GNU extension. Please define long-named options that are equivalent to the single-letter Unix-style options. We hope to make GNU more user @@ -841,7 +839,7 @@ File: standards.info, Node: Option Table, Next: Memory Usage, Prev: Command-L Table of Long Options ===================== - Here is a table of long options used by GNU programs. It is surely +Here is a table of long options used by GNU programs. It is surely incomplete, but we aim to list all the options that a new program might want to be compatible with. If you use names not already in the table, please send <bug-standards@gnu.org> a list of them, with their @@ -1931,7 +1929,7 @@ File: standards.info, Node: Memory Usage, Next: File Usage, Prev: Option Tabl Memory Usage ============ - If a program typically uses just a few meg of memory, don't bother +If a program typically uses just a few meg of memory, don't bother making any effort to reduce memory usage. For example, if it is impractical for other reasons to operate on files more than a few meg long, it is reasonable to read entire input files into core to operate @@ -1954,7 +1952,7 @@ File: standards.info, Node: File Usage, Prev: Memory Usage, Up: Program Behav File Usage ========== - Programs should be prepared to operate when `/usr' and `/etc' are +Programs should be prepared to operate when `/usr' and `/etc' are read-only file systems. Thus, if the program manages log files, lock files, backup files, score files, or any other files which are modified for internal purposes, these files should not be stored in `/usr' or @@ -1973,7 +1971,7 @@ File: standards.info, Node: Writing C, Next: Documentation, Prev: Program Beh Making The Best Use of C ************************ - This node provides advice on how best to use the C language when +This node provides advice on how best to use the C language when writing GNU software. * Menu: @@ -1994,7 +1992,7 @@ File: standards.info, Node: Formatting, Next: Comments, Up: Writing C Formatting Your Source Code =========================== - It is important to put the open-brace that starts the body of a C +It is important to put the open-brace that starts the body of a C function in column zero, and avoid putting any other open-brace or open-parenthesis or open-bracket in column zero. Several tools look for open-braces in column zero to find the beginnings of C functions. @@ -2113,8 +2111,8 @@ File: standards.info, Node: Comments, Next: Syntactic Conventions, Prev: Form Commenting Your Work ==================== - Every program should start with a comment saying briefly what it is -for. Example: `fmt - filter for simple filling of text'. +Every program should start with a comment saying briefly what it is for. +Example: `fmt - filter for simple filling of text'. Please write the comments in a GNU program in English, because English is the one language that nearly all programmers in all @@ -2193,7 +2191,7 @@ File: standards.info, Node: Syntactic Conventions, Next: Names, Prev: Comment Clean Use of C Constructs ========================= - Please explicitly declare the types of all objects. For example, you +Please explicitly declare the types of all objects. For example, you should explicitly declare all arguments to functions, and you should declare functions to return `int' rather than omitting the `int'. @@ -2306,7 +2304,7 @@ File: standards.info, Node: Names, Next: System Portability, Prev: Syntactic Naming Variables, Functions, and Files ====================================== - The names of global variables and functions in a program serve as +The names of global variables and functions in a program serve as comments of a sort. So don't choose terse names--instead, look for names that give useful information about the meaning of the variable or function. In a GNU program, names should be English, like other @@ -2355,7 +2353,7 @@ File: standards.info, Node: System Portability, Next: CPU Portability, Prev: Portability between System Types ================================ - In the Unix world, "portability" refers to porting to different Unix +In the Unix world, "portability" refers to porting to different Unix versions. For a GNU program, this kind of portability is desirable, but not paramount. @@ -2405,7 +2403,7 @@ File: standards.info, Node: CPU Portability, Next: System Functions, Prev: Sy Portability between CPUs ======================== - Even GNU systems will differ because of differences among CPU +Even GNU systems will differ because of differences among CPU types--for example, difference in byte ordering and alignment requirements. It is absolutely essential to handle these differences. However, don't make any effort to cater to the possibility that an @@ -2481,7 +2479,7 @@ File: standards.info, Node: System Functions, Next: Internationalization, Pre Calling System Functions ======================== - C implementations differ substantially. Standard C reduces but does +C implementations differ substantially. Standard C reduces but does not eliminate the incompatibilities; meanwhile, many GNU packages still support pre-standard compilers because this is not hard to do. This chapter gives recommendations for how to use the more-or-less standard C @@ -2596,8 +2594,8 @@ File: standards.info, Node: Internationalization, Next: Mmap, Prev: System Fu Internationalization ==================== - GNU has a library called GNU gettext that makes it easy to translate -the messages in a program into various languages. You should use this +GNU has a library called GNU gettext that makes it easy to translate the +messages in a program into various languages. You should use this library in every program. Use English for the messages as they appear in the program, and let gettext provide the way to translate them into other languages. @@ -2676,7 +2674,7 @@ File: standards.info, Node: Mmap, Prev: Internationalization, Up: Writing C Mmap ==== - Don't assume that `mmap' either works on all files or fails for all +Don't assume that `mmap' either works on all files or fails for all files. It may work on some files and fail on others. The proper way to use `mmap' is to try it on the specific file for @@ -2695,9 +2693,9 @@ File: standards.info, Node: Documentation, Next: Managing Releases, Prev: Wri Documenting Programs ******************** - A GNU program should ideally come with full free documentation, -adequate for both reference and tutorial purposes. If the package can -be programmed or extended, the documentation should cover programming or +A GNU program should ideally come with full free documentation, adequate +for both reference and tutorial purposes. If the package can be +programmed or extended, the documentation should cover programming or extending it, as well as just using it. * Menu: @@ -2720,7 +2718,7 @@ File: standards.info, Node: GNU Manuals, Next: Doc Strings and Manuals, Up: D GNU Manuals =========== - The preferred document format for the GNU system is the Texinfo +The preferred document format for the GNU system is the Texinfo formatting language. Every GNU package should (ideally) have documentation in Texinfo both for reference and for learners. Texinfo makes it possible to produce a good quality formatted book, using TeX, @@ -2818,11 +2816,11 @@ File: standards.info, Node: Doc Strings and Manuals, Next: Manual Structure De Doc Strings and Manuals ======================= - Some programming systems, such as Emacs, provide a documentation -string for each function, command or variable. You may be tempted to -write a reference manual by compiling the documentation strings and -writing a little additional text to go around them--but you must not do -it. That approach is a fundamental mistake. The text of well-written +Some programming systems, such as Emacs, provide a documentation string +for each function, command or variable. You may be tempted to write a +reference manual by compiling the documentation strings and writing a +little additional text to go around them--but you must not do it. That +approach is a fundamental mistake. The text of well-written documentation strings will be entirely wrong for a manual. A documentation string needs to stand alone--when it appears on the @@ -2848,10 +2846,10 @@ File: standards.info, Node: Manual Structure Details, Next: License for Manual Manual Structure Details ======================== - The title page of the manual should state the version of the -programs or packages documented in the manual. The Top node of the -manual should also contain this information. If the manual is changing -more frequently than or independent of the program, also state a version +The title page of the manual should state the version of the programs or +packages documented in the manual. The Top node of the manual should +also contain this information. If the manual is changing more +frequently than or independent of the program, also state a version number for the manual in both of these places. Each program documented in the manual should have a node named @@ -2878,8 +2876,8 @@ File: standards.info, Node: License for Manuals, Next: Manual Credits, Prev: License for Manuals =================== - Please use the GNU Free Documentation License for all GNU manuals -that are more than a few pages long. Likewise for a collection of short +Please use the GNU Free Documentation License for all GNU manuals that +are more than a few pages long. Likewise for a collection of short documents--you only need one copy of the GNU FDL for the whole collection. For a single short document, you can use a very permissive non-copyleft license, to avoid taking up space with a long license. @@ -2900,10 +2898,10 @@ File: standards.info, Node: Manual Credits, Next: Printed Manuals, Prev: Lice Manual Credits ============== - Please credit the principal human writers of the manual as the -authors, on the title page of the manual. If a company sponsored the -work, thank the company in a suitable place in the manual, but do not -cite the company as an author. +Please credit the principal human writers of the manual as the authors, +on the title page of the manual. If a company sponsored the work, thank +the company in a suitable place in the manual, but do not cite the +company as an author. File: standards.info, Node: Printed Manuals, Next: NEWS File, Prev: Manual Credits, Up: Documentation @@ -2911,12 +2909,12 @@ File: standards.info, Node: Printed Manuals, Next: NEWS File, Prev: Manual Cr Printed Manuals =============== - The FSF publishes some GNU manuals in printed form. To encourage -sales of these manuals, the on-line versions of the manual should -mention at the very start that the printed manual is available and -should point at information for getting it--for instance, with a link -to the page <http://www.gnu.org/order/order.html>. This should not be -included in the printed manual, though, because there it is redundant. +The FSF publishes some GNU manuals in printed form. To encourage sales +of these manuals, the on-line versions of the manual should mention at +the very start that the printed manual is available and should point at +information for getting it--for instance, with a link to the page +<http://www.gnu.org/order/order.html>. This should not be included in +the printed manual, though, because there it is redundant. It is also useful to explain in the on-line forms of the manual how the user can print out the manual from the sources. @@ -2927,11 +2925,11 @@ File: standards.info, Node: NEWS File, Next: Change Logs, Prev: Printed Manua The NEWS File ============= - In addition to its manual, the package should have a file named -`NEWS' which contains a list of user-visible changes worth mentioning. -In each new release, add items to the front of the file and identify -the version they pertain to. Don't discard old items; leave them in -the file after the newer items. This way, a user upgrading from any +In addition to its manual, the package should have a file named `NEWS' +which contains a list of user-visible changes worth mentioning. In +each new release, add items to the front of the file and identify the +version they pertain to. Don't discard old items; leave them in the +file after the newer items. This way, a user upgrading from any previous version can see what is new. If the `NEWS' file gets very long, move some of the older items into @@ -2944,7 +2942,7 @@ File: standards.info, Node: Change Logs, Next: Man Pages, Prev: NEWS File, U Change Logs =========== - Keep a change log to describe all the changes made to program source +Keep a change log to describe all the changes made to program source files. The purpose of this is so that people investigating bugs in the future will know about the changes that might have introduced the bug. Often a new bug can be found by looking at what was recently changed. @@ -2966,7 +2964,7 @@ File: standards.info, Node: Change Log Concepts, Next: Style of Change Logs, Change Log Concepts ------------------- - You can think of the change log as a conceptual "undo list" which +You can think of the change log as a conceptual "undo list" which explains how earlier versions were different from the current version. People can see the current version; they don't need the change log to tell them what is in it. What they want from a change log is a clear @@ -3004,8 +3002,8 @@ File: standards.info, Node: Style of Change Logs, Next: Simple Changes, Prev: Style of Change Logs -------------------- - Here are some simple examples of change log entries, starting with -the header line that says who made the change and when, followed by +Here are some simple examples of change log entries, starting with the +header line that says who made the change and when, followed by descriptions of specific changes. (These examples are drawn from Emacs and GCC.) @@ -3053,7 +3051,7 @@ File: standards.info, Node: Simple Changes, Next: Conditional Changes, Prev: Simple Changes -------------- - Certain simple kinds of changes don't need much detail in the change +Certain simple kinds of changes don't need much detail in the change log. When you change the calling sequence of a function in a simple @@ -3082,10 +3080,10 @@ File: standards.info, Node: Conditional Changes, Next: Indicating the Part Cha Conditional Changes ------------------- - C programs often contain compile-time `#if' conditionals. Many -changes are conditional; sometimes you add a new definition which is -entirely contained in a conditional. It is very useful to indicate in -the change log the conditions for which the change applies. +C programs often contain compile-time `#if' conditionals. Many changes +are conditional; sometimes you add a new definition which is entirely +contained in a conditional. It is very useful to indicate in the +change log the conditions for which the change applies. Our convention for indicating conditional changes is to use square brackets around the name of the condition. @@ -3118,7 +3116,7 @@ File: standards.info, Node: Indicating the Part Changed, Prev: Conditional Cha Indicating the Part Changed --------------------------- - Indicate the part of a function which changed by using angle brackets +Indicate the part of a function which changed by using angle brackets enclosing an indication of what the changed part does. Here is an entry for a change in the part of the function `sh-while-getopts' that deals with `sh' commands: @@ -3132,7 +3130,7 @@ File: standards.info, Node: Man Pages, Next: Reading other Manuals, Prev: Cha Man Pages ========= - In the GNU project, man pages are secondary. It is not necessary or +In the GNU project, man pages are secondary. It is not necessary or expected for every GNU program to have a man page, but some of them do. It's your choice whether to include a man page in your program. @@ -3166,7 +3164,7 @@ File: standards.info, Node: Reading other Manuals, Prev: Man Pages, Up: Docum Reading other Manuals ===================== - There may be non-free books or documentation files that describe the +There may be non-free books or documentation files that describe the program you are documenting. It is ok to use these documents for reference, just as the author of @@ -3184,7 +3182,7 @@ File: standards.info, Node: Managing Releases, Next: References, Prev: Docume The Release Process ******************* - Making a release is more than just bundling up your source files in a +Making a release is more than just bundling up your source files in a tar file and putting it up for FTP. You should set up your software so that it can be configured to run on a variety of systems. Your Makefile should conform to the GNU standards described below, and your directory @@ -3204,7 +3202,7 @@ File: standards.info, Node: Configuration, Next: Makefile Conventions, Up: Ma How Configuration Should Work ============================= - Each GNU distribution should come with a shell script named +Each GNU distribution should come with a shell script named `configure'. This script is given arguments which describe the kind of machine and system you want to compile the program for. @@ -3351,7 +3349,7 @@ File: standards.info, Node: Makefile Conventions, Next: Releases, Prev: Confi Makefile Conventions ==================== - This node describes conventions for writing the Makefiles for GNU +This node describes conventions for writing the Makefiles for GNU programs. Using Automake will help you write a Makefile that follows these conventions. @@ -3371,7 +3369,7 @@ File: standards.info, Node: Makefile Basics, Next: Utilities in Makefiles, Up General Conventions for Makefiles --------------------------------- - Every Makefile should contain this line: +Every Makefile should contain this line: SHELL = /bin/sh @@ -3451,7 +3449,7 @@ File: standards.info, Node: Utilities in Makefiles, Next: Command Variables, Utilities in Makefiles ---------------------- - Write the Makefile commands (and any shell scripts, such as +Write the Makefile commands (and any shell scripts, such as `configure') to run in `sh', not in `csh'. Don't use any special features of `ksh' or `bash'. @@ -3506,7 +3504,7 @@ File: standards.info, Node: Command Variables, Next: Directory Variables, Pre Variables for Specifying Commands --------------------------------- - Makefiles should provide variables for overriding certain commands, +Makefiles should provide variables for overriding certain commands, options, and so on. In particular, you should run most utility programs via variables. @@ -3586,8 +3584,8 @@ File: standards.info, Node: Directory Variables, Next: Standard Targets, Prev Variables for Installation Directories -------------------------------------- - Installation directories should always be named by variables, so it -is easy to install in a nonstandard place. The standard names for these +Installation directories should always be named by variables, so it is +easy to install in a nonstandard place. The standard names for these variables are described below. They are based on a standard filesystem layout; variants of it are used in SVR4, 4.4BSD, GNU/Linux, Ultrix v4, and other modern operating systems. @@ -3834,8 +3832,7 @@ File: standards.info, Node: Standard Targets, Next: Install Command Categories Standard Targets for Users -------------------------- - All GNU programs should have the following targets in their -Makefiles: +All GNU programs should have the following targets in their Makefiles: `all' Compile the entire program. This should be the default target. @@ -4092,9 +4089,9 @@ File: standards.info, Node: Install Command Categories, Prev: Standard Targets Install Command Categories -------------------------- - When writing the `install' target, you must classify all the -commands into three categories: normal ones, "pre-installation" -commands and "post-installation" commands. +When writing the `install' target, you must classify all the commands +into three categories: normal ones, "pre-installation" commands and +"post-installation" commands. Normal commands move files into their proper places, and set their modes. They may not alter any files except the ones that come entirely @@ -4198,7 +4195,7 @@ File: standards.info, Node: Releases, Prev: Makefile Conventions, Up: Managin Making Releases =============== - Package the distribution of `Foo version 69.96' up in a gzipped tar +Package the distribution of `Foo version 69.96' up in a gzipped tar file with the name `foo-69.96.tar.gz'. It should unpack into a subdirectory named `foo-69.96'. @@ -4280,7 +4277,7 @@ File: standards.info, Node: References, Next: Copying This Manual, Prev: Mana References to Non-Free Software and Documentation ************************************************* - A GNU program should not recommend use of any non-free program. We +A GNU program should not recommend use of any non-free program. We can't stop some people from writing proprietary programs, or stop other people from using them, but we can and should avoid helping to advertise them to new potential customers. Proprietary software is a @@ -4678,7 +4675,7 @@ GNU Free Documentation License ADDENDUM: How to use this License for your documents ==================================================== - To use this License in a document you have written, include a copy of +To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page: @@ -4830,67 +4827,67 @@ Index Tag Table: Node: Top689 -Node: Preface1392 -Node: Legal Issues3611 -Node: Reading Non-Free Code4074 -Node: Contributions5797 -Node: Trademarks7946 -Node: Design Advice9004 -Node: Source Language9587 -Node: Compatibility11594 -Node: Using Extensions13217 -Node: Standard C14788 -Node: Conditional Compilation17186 -Node: Program Behavior18480 -Node: Semantics19398 -Node: Libraries24086 -Node: Errors25326 -Node: User Interfaces27102 -Node: Graphical Interfaces28702 -Node: Command-Line Interfaces29732 -Node: Option Table35798 -Node: Memory Usage50802 -Node: File Usage51822 -Node: Writing C52565 -Node: Formatting53414 -Node: Comments57472 -Node: Syntactic Conventions60770 -Node: Names64177 -Node: System Portability66381 -Node: CPU Portability68761 -Node: System Functions72012 -Node: Internationalization77214 -Node: Mmap80362 -Node: Documentation81067 -Node: GNU Manuals82171 -Node: Doc Strings and Manuals87223 -Node: Manual Structure Details88771 -Node: License for Manuals90184 -Node: Manual Credits91153 -Node: Printed Manuals91541 -Node: NEWS File92222 -Node: Change Logs92894 -Node: Change Log Concepts93643 -Node: Style of Change Logs95498 -Node: Simple Changes97544 -Node: Conditional Changes98779 -Node: Indicating the Part Changed100192 -Node: Man Pages100710 -Node: Reading other Manuals102329 -Node: Managing Releases103113 -Node: Configuration103875 -Node: Makefile Conventions110775 -Node: Makefile Basics111576 -Node: Utilities in Makefiles114741 -Node: Command Variables116877 -Node: Directory Variables120445 -Node: Standard Targets131330 -Ref: Standard Targets-Footnote-1142581 -Node: Install Command Categories142681 -Node: Releases147254 -Node: References151337 -Node: Copying This Manual153621 -Node: GNU Free Documentation License153835 -Node: Index173521 +Node: Preface1389 +Node: Legal Issues3605 +Node: Reading Non-Free Code4065 +Node: Contributions5785 +Node: Trademarks7931 +Node: Design Advice8986 +Node: Source Language9566 +Node: Compatibility11570 +Node: Using Extensions13190 +Node: Standard C14758 +Node: Conditional Compilation17153 +Node: Program Behavior18444 +Node: Semantics19359 +Node: Libraries24044 +Node: Errors25281 +Node: User Interfaces27054 +Node: Graphical Interfaces28651 +Node: Command-Line Interfaces29678 +Node: Option Table35741 +Node: Memory Usage50742 +Node: File Usage51759 +Node: Writing C52499 +Node: Formatting53345 +Node: Comments57400 +Node: Syntactic Conventions60694 +Node: Names64098 +Node: System Portability66299 +Node: CPU Portability68676 +Node: System Functions71924 +Node: Internationalization77123 +Node: Mmap80268 +Node: Documentation80970 +Node: GNU Manuals82071 +Node: Doc Strings and Manuals87120 +Node: Manual Structure Details88665 +Node: License for Manuals90075 +Node: Manual Credits91041 +Node: Printed Manuals91426 +Node: NEWS File92104 +Node: Change Logs92774 +Node: Change Log Concepts93520 +Node: Style of Change Logs95372 +Node: Simple Changes97415 +Node: Conditional Changes98647 +Node: Indicating the Part Changed100057 +Node: Man Pages100572 +Node: Reading other Manuals102188 +Node: Managing Releases102969 +Node: Configuration103728 +Node: Makefile Conventions110625 +Node: Makefile Basics111423 +Node: Utilities in Makefiles114585 +Node: Command Variables116718 +Node: Directory Variables120283 +Node: Standard Targets131165 +Ref: Standard Targets-Footnote-1142413 +Node: Install Command Categories142513 +Node: Releases147083 +Node: References151163 +Node: Copying This Manual153444 +Node: GNU Free Documentation License153658 +Node: Index173341 End Tag Table diff --git a/gnu/dist/binutils/gprof/gprof.info b/gnu/dist/binutils/gprof/gprof.info index adec19978de..74e42d986e2 100644 --- a/gnu/dist/binutils/gprof/gprof.info +++ b/gnu/dist/binutils/gprof/gprof.info @@ -1,4 +1,4 @@ -This is gprof.info, produced by makeinfo version 4.3 from gprof.texi. +This is gprof.info, produced by makeinfo version 4.6 from gprof.texi. START-INFO-DIR-ENTRY * gprof: (gprof). Profiling your program's execution @@ -6,7 +6,7 @@ END-INFO-DIR-ENTRY This file documents the gprof profiler of the GNU system. - Copyright (C) 1988, 92, 97, 98, 99, 2000, 2001 Free Software + Copyright (C) 1988, 92, 97, 98, 99, 2000, 2001, 2003 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document @@ -17,42 +17,2284 @@ Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". -Indirect: -gprof.info-1: 707 -gprof.info-2: 48575 -gprof.info-3: 82712 +File: gprof.info, Node: Top, Next: Introduction, Up: (dir) + +Profiling a Program: Where Does It Spend Its Time? +************************************************** + +This manual describes the GNU profiler, `gprof', and how you can use it +to determine which parts of a program are taking most of the execution +time. We assume that you know how to write, compile, and execute +programs. GNU `gprof' was written by Jay Fenlason. + + This document is distributed under the terms of the GNU Free +Documentation License. A copy of the license is included in the +section entitled "GNU Free Documentation License". + +* Menu: + +* Introduction:: What profiling means, and why it is useful. + +* Compiling:: How to compile your program for profiling. +* Executing:: Executing your program to generate profile data +* Invoking:: How to run `gprof', and its options + +* Output:: Interpreting `gprof''s output + +* Inaccuracy:: Potential problems you should be aware of +* How do I?:: Answers to common questions +* Incompatibilities:: (between GNU `gprof' and Unix `gprof'.) +* Details:: Details of how profiling is done +* GNU Free Documentation License:: GNU Free Documentation License + + +File: gprof.info, Node: Introduction, Next: Compiling, Prev: Top, Up: Top + +Introduction to Profiling +************************* + +Profiling allows you to learn where your program spent its time and +which functions called which other functions while it was executing. +This information can show you which pieces of your program are slower +than you expected, and might be candidates for rewriting to make your +program execute faster. It can also tell you which functions are being +called more or less often than you expected. This may help you spot +bugs that had otherwise been unnoticed. + + Since the profiler uses information collected during the actual +execution of your program, it can be used on programs that are too +large or too complex to analyze by reading the source. However, how +your program is run will affect the information that shows up in the +profile data. If you don't use some feature of your program while it +is being profiled, no profile information will be generated for that +feature. + + Profiling has several steps: + + * You must compile and link your program with profiling enabled. + *Note Compiling::. + + * You must execute your program to generate a profile data file. + *Note Executing::. + + * You must run `gprof' to analyze the profile data. *Note + Invoking::. + + The next three chapters explain these steps in greater detail. + + Several forms of output are available from the analysis. + + The "flat profile" shows how much time your program spent in each +function, and how many times that function was called. If you simply +want to know which functions burn most of the cycles, it is stated +concisely here. *Note Flat Profile::. + + The "call graph" shows, for each function, which functions called +it, which other functions it called, and how many times. There is also +an estimate of how much time was spent in the subroutines of each +function. This can suggest places where you might try to eliminate +function calls that use a lot of time. *Note Call Graph::. + + The "annotated source" listing is a copy of the program's source +code, labeled with the number of times each line of the program was +executed. *Note Annotated Source::. + + To better understand how profiling works, you may wish to read a +description of its implementation. *Note Implementation::. + + +File: gprof.info, Node: Compiling, Next: Executing, Prev: Introduction, Up: Top + +Compiling a Program for Profiling +********************************* + +The first step in generating profile information for your program is to +compile and link it with profiling enabled. + + To compile a source file for profiling, specify the `-pg' option when +you run the compiler. (This is in addition to the options you normally +use.) + + To link the program for profiling, if you use a compiler such as `cc' +to do the linking, simply specify `-pg' in addition to your usual +options. The same option, `-pg', alters either compilation or linking +to do what is necessary for profiling. Here are examples: + + cc -g -c myprog.c utils.c -pg + cc -o myprog myprog.o utils.o -pg + + The `-pg' option also works with a command that both compiles and +links: + + cc -o myprog myprog.c utils.c -g -pg + + Note: The `-pg' option must be part of your compilation options as +well as your link options. If it is not then no call-graph data will +be gathered and when you run `gprof' you will get an error message like +this: + + gprof: gmon.out file is missing call-graph data + + If you add the `-Q' switch to suppress the printing of the call +graph data you will still be able to see the time samples: + + Flat profile: + + Each sample counts as 0.01 seconds. + % cumulative self self total + time seconds seconds calls Ts/call Ts/call name + 44.12 0.07 0.07 zazLoop + 35.29 0.14 0.06 main + 20.59 0.17 0.04 bazMillion + + % the percentage of the total running time of the + + If you run the linker `ld' directly instead of through a compiler +such as `cc', you may have to specify a profiling startup file +`gcrt0.o' as the first input file instead of the usual startup file +`crt0.o'. In addition, you would probably want to specify the +profiling C library, `libc_p.a', by writing `-lc_p' instead of the +usual `-lc'. This is not absolutely necessary, but doing this gives +you number-of-calls information for standard library functions such as +`read' and `open'. For example: + + ld -o myprog /lib/gcrt0.o myprog.o utils.o -lc_p + + If you compile only some of the modules of the program with `-pg', +you can still profile the program, but you won't get complete +information about the modules that were compiled without `-pg'. The +only information you get for the functions in those modules is the +total time spent in them; there is no record of how many times they +were called, or from where. This will not affect the flat profile +(except that the `calls' field for the functions will be blank), but +will greatly reduce the usefulness of the call graph. + + If you wish to perform line-by-line profiling, you will also need to +specify the `-g' option, instructing the compiler to insert debugging +symbols into the program that match program addresses to source code +lines. *Note Line-by-line::. + + In addition to the `-pg' and `-g' options, older versions of GCC +required you to specify the `-a' option when compiling in order to +instrument it to perform basic-block counting. Newer versions do not +require this option and will not accept it; basic-block counting is +always enabled when `-pg' is on. + + When basic-block counting is enabled, as the program runs it will +count how many times it executed each branch of each `if' statement, +each iteration of each `do' loop, etc. This will enable `gprof' to +construct an annotated source code listing showing how many times each +line of code was executed. + + It also worth noting that GCC supports a different profiling method +which is enabled by the `-fprofile-arcs', `-ftest-coverage' and +`-fprofile-values' switches. These switches do not produce data which +is useful to `gprof' however, so they are not discussed further here. +There is also the `-finstrument-functions' switch which will cause GCC +to insert calls to special user supplied instrumentation routines at +the entry and exit of every function in their program. This can be +used to implement an alternative profiling scheme. + + +File: gprof.info, Node: Executing, Next: Invoking, Prev: Compiling, Up: Top + +Executing the Program +********************* + +Once the program is compiled for profiling, you must run it in order to +generate the information that `gprof' needs. Simply run the program as +usual, using the normal arguments, file names, etc. The program should +run normally, producing the same output as usual. It will, however, run +somewhat slower than normal because of the time spent collecting and the +writing the profile data. + + The way you run the program--the arguments and input that you give +it--may have a dramatic effect on what the profile information shows. +The profile data will describe the parts of the program that were +activated for the particular input you use. For example, if the first +command you give to your program is to quit, the profile data will show +the time used in initialization and in cleanup, but not much else. + + Your program will write the profile data into a file called +`gmon.out' just before exiting. If there is already a file called +`gmon.out', its contents are overwritten. There is currently no way to +tell the program to write the profile data under a different name, but +you can rename the file afterwards if you are concerned that it may be +overwritten. + + In order to write the `gmon.out' file properly, your program must +exit normally: by returning from `main' or by calling `exit'. Calling +the low-level function `_exit' does not write the profile data, and +neither does abnormal termination due to an unhandled signal. + + The `gmon.out' file is written in the program's _current working +directory_ at the time it exits. This means that if your program calls +`chdir', the `gmon.out' file will be left in the last directory your +program `chdir''d to. If you don't have permission to write in this +directory, the file is not written, and you will get an error message. + + Older versions of the GNU profiling library may also write a file +called `bb.out'. This file, if present, contains an human-readable +listing of the basic-block execution counts. Unfortunately, the +appearance of a human-readable `bb.out' means the basic-block counts +didn't get written into `gmon.out'. The Perl script `bbconv.pl', +included with the `gprof' source distribution, will convert a `bb.out' +file into a format readable by `gprof'. Invoke it like this: + + bbconv.pl < bb.out > BH-DATA + + This translates the information in `bb.out' into a form that `gprof' +can understand. But you still need to tell `gprof' about the existence +of this translated information. To do that, include BB-DATA on the +`gprof' command line, _along with `gmon.out'_, like this: + + gprof OPTIONS EXECUTABLE-FILE gmon.out BB-DATA [YET-MORE-PROFILE-DATA-FILES...] [> OUTFILE] + + +File: gprof.info, Node: Invoking, Next: Output, Prev: Executing, Up: Top + +`gprof' Command Summary +*********************** + +After you have a profile data file `gmon.out', you can run `gprof' to +interpret the information in it. The `gprof' program prints a flat +profile and a call graph on standard output. Typically you would +redirect the output of `gprof' into a file with `>'. + + You run `gprof' like this: + + gprof OPTIONS [EXECUTABLE-FILE [PROFILE-DATA-FILES...]] [> OUTFILE] + +Here square-brackets indicate optional arguments. + + If you omit the executable file name, the file `a.out' is used. If +you give no profile data file name, the file `gmon.out' is used. If +any file is not in the proper format, or if the profile data file does +not appear to belong to the executable file, an error message is +printed. + + You can give more than one profile data file by entering all their +names after the executable file name; then the statistics in all the +data files are summed together. + + The order of these options does not matter. + +* Menu: + +* Output Options:: Controlling `gprof''s output style +* Analysis Options:: Controlling how `gprof' analyses its data +* Miscellaneous Options:: +* Deprecated Options:: Options you no longer need to use, but which + have been retained for compatibility +* Symspecs:: Specifying functions to include or exclude + + +File: gprof.info, Node: Output Options, Next: Analysis Options, Up: Invoking + +Output Options +============== + +These options specify which of several output formats `gprof' should +produce. + + Many of these options take an optional "symspec" to specify +functions to be included or excluded. These options can be specified +multiple times, with different symspecs, to include or exclude sets of +symbols. *Note Symspecs::. + + Specifying any of these options overrides the default (`-p -q'), +which prints a flat profile and call graph analysis for all functions. + +`-A[SYMSPEC]' +`--annotated-source[=SYMSPEC]' + The `-A' option causes `gprof' to print annotated source code. If + SYMSPEC is specified, print output only for matching symbols. + *Note Annotated Source::. + +`-b' +`--brief' + If the `-b' option is given, `gprof' doesn't print the verbose + blurbs that try to explain the meaning of all of the fields in the + tables. This is useful if you intend to print out the output, or + are tired of seeing the blurbs. + +`-C[SYMSPEC]' +`--exec-counts[=SYMSPEC]' + The `-C' option causes `gprof' to print a tally of functions and + the number of times each was called. If SYMSPEC is specified, + print tally only for matching symbols. + + If the profile data file contains basic-block count records, + specifying the `-l' option, along with `-C', will cause basic-block + execution counts to be tallied and displayed. + +`-i' +`--file-info' + The `-i' option causes `gprof' to display summary information + about the profile data file(s) and then exit. The number of + histogram, call graph, and basic-block count records is displayed. + +`-I DIRS' +`--directory-path=DIRS' + The `-I' option specifies a list of search directories in which to + find source files. Environment variable GPROF_PATH can also be + used to convey this information. Used mostly for annotated source + output. + +`-J[SYMSPEC]' +`--no-annotated-source[=SYMSPEC]' + The `-J' option causes `gprof' not to print annotated source code. + If SYMSPEC is specified, `gprof' prints annotated source, but + excludes matching symbols. + +`-L' +`--print-path' + Normally, source filenames are printed with the path component + suppressed. The `-L' option causes `gprof' to print the full + pathname of source filenames, which is determined from symbolic + debugging information in the image file and is relative to the + directory in which the compiler was invoked. + +`-p[SYMSPEC]' +`--flat-profile[=SYMSPEC]' + The `-p' option causes `gprof' to print a flat profile. If + SYMSPEC is specified, print flat profile only for matching symbols. + *Note Flat Profile::. + +`-P[SYMSPEC]' +`--no-flat-profile[=SYMSPEC]' + The `-P' option causes `gprof' to suppress printing a flat profile. + If SYMSPEC is specified, `gprof' prints a flat profile, but + excludes matching symbols. + +`-q[SYMSPEC]' +`--graph[=SYMSPEC]' + The `-q' option causes `gprof' to print the call graph analysis. + If SYMSPEC is specified, print call graph only for matching symbols + and their children. *Note Call Graph::. + +`-Q[SYMSPEC]' +`--no-graph[=SYMSPEC]' + The `-Q' option causes `gprof' to suppress printing the call graph. + If SYMSPEC is specified, `gprof' prints a call graph, but excludes + matching symbols. + +`-y' +`--separate-files' + This option affects annotated source output only. Normally, + `gprof' prints annotated source files to standard-output. If this + option is specified, annotated source for a file named + `path/FILENAME' is generated in the file `FILENAME-ann'. If the + underlying filesystem would truncate `FILENAME-ann' so that it + overwrites the original `FILENAME', `gprof' generates annotated + source in the file `FILENAME.ann' instead (if the original file + name has an extension, that extension is _replaced_ with `.ann'). + +`-Z[SYMSPEC]' +`--no-exec-counts[=SYMSPEC]' + The `-Z' option causes `gprof' not to print a tally of functions + and the number of times each was called. If SYMSPEC is specified, + print tally, but exclude matching symbols. + +`--function-ordering' + The `--function-ordering' option causes `gprof' to print a + suggested function ordering for the program based on profiling + data. This option suggests an ordering which may improve paging, + tlb and cache behavior for the program on systems which support + arbitrary ordering of functions in an executable. + + The exact details of how to force the linker to place functions in + a particular order is system dependent and out of the scope of this + manual. + +`--file-ordering MAP_FILE' + The `--file-ordering' option causes `gprof' to print a suggested + .o link line ordering for the program based on profiling data. + This option suggests an ordering which may improve paging, tlb and + cache behavior for the program on systems which do not support + arbitrary ordering of functions in an executable. + + Use of the `-a' argument is highly recommended with this option. + + The MAP_FILE argument is a pathname to a file which provides + function name to object file mappings. The format of the file is + similar to the output of the program `nm'. + + c-parse.o:00000000 T yyparse + c-parse.o:00000004 C yyerrflag + c-lang.o:00000000 T maybe_objc_method_name + c-lang.o:00000000 T print_lang_statistics + c-lang.o:00000000 T recognize_objc_keyword + c-decl.o:00000000 T print_lang_identifier + c-decl.o:00000000 T print_lang_type + ... + + To create a MAP_FILE with GNU `nm', type a command like `nm + --extern-only --defined-only -v --print-file-name program-name'. + +`-T' +`--traditional' + The `-T' option causes `gprof' to print its output in + "traditional" BSD style. + +`-w WIDTH' +`--width=WIDTH' + Sets width of output lines to WIDTH. Currently only used when + printing the function index at the bottom of the call graph. + +`-x' +`--all-lines' + This option affects annotated source output only. By default, + only the lines at the beginning of a basic-block are annotated. + If this option is specified, every line in a basic-block is + annotated by repeating the annotation for the first line. This + behavior is similar to `tcov''s `-a'. + +`--demangle[=STYLE]' +`--no-demangle' + These options control whether C++ symbol names should be demangled + when printing output. The default is to demangle symbols. The + `--no-demangle' option may be used to turn off demangling. + Different compilers have different mangling styles. The optional + demangling style argument can be used to choose an appropriate + demangling style for your compiler. + + +File: gprof.info, Node: Analysis Options, Next: Miscellaneous Options, Prev: Output Options, Up: Invoking + +Analysis Options +================ + +`-a' +`--no-static' + The `-a' option causes `gprof' to suppress the printing of + statically declared (private) functions. (These are functions + whose names are not listed as global, and which are not visible + outside the file/function/block where they were defined.) Time + spent in these functions, calls to/from them, etc, will all be + attributed to the function that was loaded directly before it in + the executable file. This option affects both the flat profile + and the call graph. + +`-c' +`--static-call-graph' + The `-c' option causes the call graph of the program to be + augmented by a heuristic which examines the text space of the + object file and identifies function calls in the binary machine + code. Since normal call graph records are only generated when + functions are entered, this option identifies children that could + have been called, but never were. Calls to functions that were + not compiled with profiling enabled are also identified, but only + if symbol table entries are present for them. Calls to dynamic + library routines are typically _not_ found by this option. + Parents or children identified via this heuristic are indicated in + the call graph with call counts of `0'. + +`-D' +`--ignore-non-functions' + The `-D' option causes `gprof' to ignore symbols which are not + known to be functions. This option will give more accurate + profile data on systems where it is supported (Solaris and HPUX for + example). + +`-k FROM/TO' + The `-k' option allows you to delete from the call graph any arcs + from symbols matching symspec FROM to those matching symspec TO. + +`-l' +`--line' + The `-l' option enables line-by-line profiling, which causes + histogram hits to be charged to individual source code lines, + instead of functions. If the program was compiled with + basic-block counting enabled, this option will also identify how + many times each line of code was executed. While line-by-line + profiling can help isolate where in a large function a program is + spending its time, it also significantly increases the running + time of `gprof', and magnifies statistical inaccuracies. *Note + Sampling Error::. + +`-m NUM' +`--min-count=NUM' + This option affects execution count output only. Symbols that are + executed less than NUM times are suppressed. + +`-n[SYMSPEC]' +`--time[=SYMSPEC]' + The `-n' option causes `gprof', in its call graph analysis, to + only propagate times for symbols matching SYMSPEC. + +`-N[SYMSPEC]' +`--no-time[=SYMSPEC]' + The `-n' option causes `gprof', in its call graph analysis, not to + propagate times for symbols matching SYMSPEC. + +`-z' +`--display-unused-functions' + If you give the `-z' option, `gprof' will mention all functions in + the flat profile, even those that were never called, and that had + no time spent in them. This is useful in conjunction with the + `-c' option for discovering which routines were never called. + + + +File: gprof.info, Node: Miscellaneous Options, Next: Deprecated Options, Prev: Analysis Options, Up: Invoking + +Miscellaneous Options +===================== + +`-d[NUM]' +`--debug[=NUM]' + The `-d NUM' option specifies debugging options. If NUM is not + specified, enable all debugging. *Note Debugging::. + +`-ONAME' +`--file-format=NAME' + Selects the format of the profile data files. Recognized formats + are `auto' (the default), `bsd', `4.4bsd', `magic', and `prof' + (not yet supported). + +`-s' +`--sum' + The `-s' option causes `gprof' to summarize the information in the + profile data files it read in, and write out a profile data file + called `gmon.sum', which contains all the information from the + profile data files that `gprof' read in. The file `gmon.sum' may + be one of the specified input files; the effect of this is to + merge the data in the other input files into `gmon.sum'. + + Eventually you can run `gprof' again without `-s' to analyze the + cumulative data in the file `gmon.sum'. + +`-v' +`--version' + The `-v' flag causes `gprof' to print the current version number, + and then exit. + + + +File: gprof.info, Node: Deprecated Options, Next: Symspecs, Prev: Miscellaneous Options, Up: Invoking + +Deprecated Options +================== + + These options have been replaced with newer versions that use + symspecs. + +`-e FUNCTION_NAME' + The `-e FUNCTION' option tells `gprof' to not print information + about the function FUNCTION_NAME (and its children...) in the call + graph. The function will still be listed as a child of any + functions that call it, but its index number will be shown as + `[not printed]'. More than one `-e' option may be given; only one + FUNCTION_NAME may be indicated with each `-e' option. + +`-E FUNCTION_NAME' + The `-E FUNCTION' option works like the `-e' option, but time + spent in the function (and children who were not called from + anywhere else), will not be used to compute the + percentages-of-time for the call graph. More than one `-E' option + may be given; only one FUNCTION_NAME may be indicated with each + `-E' option. + +`-f FUNCTION_NAME' + The `-f FUNCTION' option causes `gprof' to limit the call graph to + the function FUNCTION_NAME and its children (and their + children...). More than one `-f' option may be given; only one + FUNCTION_NAME may be indicated with each `-f' option. + +`-F FUNCTION_NAME' + The `-F FUNCTION' option works like the `-f' option, but only time + spent in the function and its children (and their children...) + will be used to determine total-time and percentages-of-time for + the call graph. More than one `-F' option may be given; only one + FUNCTION_NAME may be indicated with each `-F' option. The `-F' + option overrides the `-E' option. + + + Note that only one function can be specified with each `-e', `-E', +`-f' or `-F' option. To specify more than one function, use multiple +options. For example, this command: + + gprof -e boring -f foo -f bar myprogram > gprof.output + +lists in the call graph all functions that were reached from either +`foo' or `bar' and were not reachable from `boring'. + + +File: gprof.info, Node: Symspecs, Prev: Deprecated Options, Up: Invoking + +Symspecs +======== + +Many of the output options allow functions to be included or excluded +using "symspecs" (symbol specifications), which observe the following +syntax: + + filename_containing_a_dot + | funcname_not_containing_a_dot + | linenumber + | ( [ any_filename ] `:' ( any_funcname | linenumber ) ) + + Here are some sample symspecs: + +`main.c' + Selects everything in file `main.c'--the dot in the string tells + `gprof' to interpret the string as a filename, rather than as a + function name. To select a file whose name does not contain a + dot, a trailing colon should be specified. For example, `odd:' is + interpreted as the file named `odd'. + +`main' + Selects all functions named `main'. + + Note that there may be multiple instances of the same function name + because some of the definitions may be local (i.e., static). + Unless a function name is unique in a program, you must use the + colon notation explained below to specify a function from a + specific source file. + + Sometimes, function names contain dots. In such cases, it is + necessary to add a leading colon to the name. For example, + `:.mul' selects function `.mul'. + + In some object file formats, symbols have a leading underscore. + `gprof' will normally not print these underscores. When you name a + symbol in a symspec, you should type it exactly as `gprof' prints + it in its output. For example, if the compiler produces a symbol + `_main' from your `main' function, `gprof' still prints it as + `main' in its output, so you should use `main' in symspecs. + +`main.c:main' + Selects function `main' in file `main.c'. + +`main.c:134' + Selects line 134 in file `main.c'. + + +File: gprof.info, Node: Output, Next: Inaccuracy, Prev: Invoking, Up: Top + +Interpreting `gprof''s Output +***************************** + +`gprof' can produce several different output styles, the most important +of which are described below. The simplest output styles (file +information, execution count, and function and file ordering) are not +described here, but are documented with the respective options that +trigger them. *Note Output Options::. + +* Menu: + +* Flat Profile:: The flat profile shows how much time was spent + executing directly in each function. +* Call Graph:: The call graph shows which functions called which + others, and how much time each function used + when its subroutine calls are included. +* Line-by-line:: `gprof' can analyze individual source code lines +* Annotated Source:: The annotated source listing displays source code + labeled with execution counts + + +File: gprof.info, Node: Flat Profile, Next: Call Graph, Up: Output + +The Flat Profile +================ + +The "flat profile" shows the total amount of time your program spent +executing each function. Unless the `-z' option is given, functions +with no apparent time spent in them, and no apparent calls to them, are +not mentioned. Note that if a function was not compiled for profiling, +and didn't run long enough to show up on the program counter histogram, +it will be indistinguishable from a function that was never called. + + This is part of a flat profile for a small program: + + Flat profile: + + Each sample counts as 0.01 seconds. + % cumulative self self total + time seconds seconds calls ms/call ms/call name + 33.34 0.02 0.02 7208 0.00 0.00 open + 16.67 0.03 0.01 244 0.04 0.12 offtime + 16.67 0.04 0.01 8 1.25 1.25 memccpy + 16.67 0.05 0.01 7 1.43 1.43 write + 16.67 0.06 0.01 mcount + 0.00 0.06 0.00 236 0.00 0.00 tzset + 0.00 0.06 0.00 192 0.00 0.00 tolower + 0.00 0.06 0.00 47 0.00 0.00 strlen + 0.00 0.06 0.00 45 0.00 0.00 strchr + 0.00 0.06 0.00 1 0.00 50.00 main + 0.00 0.06 0.00 1 0.00 0.00 memcpy + 0.00 0.06 0.00 1 0.00 10.11 print + 0.00 0.06 0.00 1 0.00 0.00 profil + 0.00 0.06 0.00 1 0.00 50.00 report + ... + +The functions are sorted by first by decreasing run-time spent in them, +then by decreasing number of calls, then alphabetically by name. The +functions `mcount' and `profil' are part of the profiling apparatus and +appear in every flat profile; their time gives a measure of the amount +of overhead due to profiling. + + Just before the column headers, a statement appears indicating how +much time each sample counted as. This "sampling period" estimates the +margin of error in each of the time figures. A time figure that is not +much larger than this is not reliable. In this example, each sample +counted as 0.01 seconds, suggesting a 100 Hz sampling rate. The +program's total execution time was 0.06 seconds, as indicated by the +`cumulative seconds' field. Since each sample counted for 0.01 +seconds, this means only six samples were taken during the run. Two of +the samples occurred while the program was in the `open' function, as +indicated by the `self seconds' field. Each of the other four samples +occurred one each in `offtime', `memccpy', `write', and `mcount'. +Since only six samples were taken, none of these values can be regarded +as particularly reliable. In another run, the `self seconds' field for +`mcount' might well be `0.00' or `0.02'. *Note Sampling Error::, for a +complete discussion. + + The remaining functions in the listing (those whose `self seconds' +field is `0.00') didn't appear in the histogram samples at all. +However, the call graph indicated that they were called, so therefore +they are listed, sorted in decreasing order by the `calls' field. +Clearly some time was spent executing these functions, but the paucity +of histogram samples prevents any determination of how much time each +took. + + Here is what the fields in each line mean: + +`% time' + This is the percentage of the total execution time your program + spent in this function. These should all add up to 100%. + +`cumulative seconds' + This is the cumulative total number of seconds the computer spent + executing this functions, plus the time spent in all the functions + above this one in this table. + +`self seconds' + This is the number of seconds accounted for by this function alone. + The flat profile listing is sorted first by this number. + +`calls' + This is the total number of times the function was called. If the + function was never called, or the number of times it was called + cannot be determined (probably because the function was not + compiled with profiling enabled), the "calls" field is blank. + +`self ms/call' + This represents the average number of milliseconds spent in this + function per call, if this function is profiled. Otherwise, this + field is blank for this function. + +`total ms/call' + This represents the average number of milliseconds spent in this + function and its descendants per call, if this function is + profiled. Otherwise, this field is blank for this function. This + is the only field in the flat profile that uses call graph + analysis. + +`name' + This is the name of the function. The flat profile is sorted by + this field alphabetically after the "self seconds" and "calls" + fields are sorted. + + +File: gprof.info, Node: Call Graph, Next: Line-by-line, Prev: Flat Profile, Up: Output + +The Call Graph +============== + +The "call graph" shows how much time was spent in each function and its +children. From this information, you can find functions that, while +they themselves may not have used much time, called other functions +that did use unusual amounts of time. + + Here is a sample call from a small program. This call came from the +same `gprof' run as the flat profile example in the previous chapter. + + granularity: each sample hit covers 2 byte(s) for 20.00% of 0.05 seconds + + index % time self children called name + <spontaneous> + [1] 100.0 0.00 0.05 start [1] + 0.00 0.05 1/1 main [2] + 0.00 0.00 1/2 on_exit [28] + 0.00 0.00 1/1 exit [59] + ----------------------------------------------- + 0.00 0.05 1/1 start [1] + [2] 100.0 0.00 0.05 1 main [2] + 0.00 0.05 1/1 report [3] + ----------------------------------------------- + 0.00 0.05 1/1 main [2] + [3] 100.0 0.00 0.05 1 report [3] + 0.00 0.03 8/8 timelocal [6] + 0.00 0.01 1/1 print [9] + 0.00 0.01 9/9 fgets [12] + 0.00 0.00 12/34 strncmp <cycle 1> [40] + 0.00 0.00 8/8 lookup [20] + 0.00 0.00 1/1 fopen [21] + 0.00 0.00 8/8 chewtime [24] + 0.00 0.00 8/16 skipspace [44] + ----------------------------------------------- + [4] 59.8 0.01 0.02 8+472 <cycle 2 as a whole> [4] + 0.01 0.02 244+260 offtime <cycle 2> [7] + 0.00 0.00 236+1 tzset <cycle 2> [26] + ----------------------------------------------- + + The lines full of dashes divide this table into "entries", one for +each function. Each entry has one or more lines. + + In each entry, the primary line is the one that starts with an index +number in square brackets. The end of this line says which function +the entry is for. The preceding lines in the entry describe the +callers of this function and the following lines describe its +subroutines (also called "children" when we speak of the call graph). + + The entries are sorted by time spent in the function and its +subroutines. + + The internal profiling function `mcount' (*note Flat Profile::) is +never mentioned in the call graph. + +* Menu: + +* Primary:: Details of the primary line's contents. +* Callers:: Details of caller-lines' contents. +* Subroutines:: Details of subroutine-lines' contents. +* Cycles:: When there are cycles of recursion, + such as `a' calls `b' calls `a'... + + +File: gprof.info, Node: Primary, Next: Callers, Up: Call Graph + +The Primary Line +---------------- + +The "primary line" in a call graph entry is the line that describes the +function which the entry is about and gives the overall statistics for +this function. + + For reference, we repeat the primary line from the entry for function +`report' in our main example, together with the heading line that shows +the names of the fields: + + index % time self children called name + ... + [3] 100.0 0.00 0.05 1 report [3] + + Here is what the fields in the primary line mean: + +`index' + Entries are numbered with consecutive integers. Each function + therefore has an index number, which appears at the beginning of + its primary line. + + Each cross-reference to a function, as a caller or subroutine of + another, gives its index number as well as its name. The index + number guides you if you wish to look for the entry for that + function. + +`% time' + This is the percentage of the total time that was spent in this + function, including time spent in subroutines called from this + function. + + The time spent in this function is counted again for the callers of + this function. Therefore, adding up these percentages is + meaningless. + +`self' + This is the total amount of time spent in this function. This + should be identical to the number printed in the `seconds' field + for this function in the flat profile. + +`children' + This is the total amount of time spent in the subroutine calls + made by this function. This should be equal to the sum of all the + `self' and `children' entries of the children listed directly + below this function. + +`called' + This is the number of times the function was called. + + If the function called itself recursively, there are two numbers, + separated by a `+'. The first number counts non-recursive calls, + and the second counts recursive calls. + + In the example above, the function `report' was called once from + `main'. + +`name' + This is the name of the current function. The index number is + repeated after it. + + If the function is part of a cycle of recursion, the cycle number + is printed between the function's name and the index number (*note + Cycles::). For example, if function `gnurr' is part of cycle + number one, and has index number twelve, its primary line would be + end like this: + + gnurr <cycle 1> [12] + + +File: gprof.info, Node: Callers, Next: Subroutines, Prev: Primary, Up: Call Graph + +Lines for a Function's Callers +------------------------------ + +A function's entry has a line for each function it was called by. +These lines' fields correspond to the fields of the primary line, but +their meanings are different because of the difference in context. + + For reference, we repeat two lines from the entry for the function +`report', the primary line and one caller-line preceding it, together +with the heading line that shows the names of the fields: + + index % time self children called name + ... + 0.00 0.05 1/1 main [2] + [3] 100.0 0.00 0.05 1 report [3] + + Here are the meanings of the fields in the caller-line for `report' +called from `main': + +`self' + An estimate of the amount of time spent in `report' itself when it + was called from `main'. + +`children' + An estimate of the amount of time spent in subroutines of `report' + when `report' was called from `main'. + + The sum of the `self' and `children' fields is an estimate of the + amount of time spent within calls to `report' from `main'. + +`called' + Two numbers: the number of times `report' was called from `main', + followed by the total number of non-recursive calls to `report' + from all its callers. + +`name and index number' + The name of the caller of `report' to which this line applies, + followed by the caller's index number. + + Not all functions have entries in the call graph; some options to + `gprof' request the omission of certain functions. When a caller + has no entry of its own, it still has caller-lines in the entries + of the functions it calls. + + If the caller is part of a recursion cycle, the cycle number is + printed between the name and the index number. + + If the identity of the callers of a function cannot be determined, a +dummy caller-line is printed which has `<spontaneous>' as the "caller's +name" and all other fields blank. This can happen for signal handlers. + + +File: gprof.info, Node: Subroutines, Next: Cycles, Prev: Callers, Up: Call Graph + +Lines for a Function's Subroutines +---------------------------------- + +A function's entry has a line for each of its subroutines--in other +words, a line for each other function that it called. These lines' +fields correspond to the fields of the primary line, but their meanings +are different because of the difference in context. + + For reference, we repeat two lines from the entry for the function +`main', the primary line and a line for a subroutine, together with the +heading line that shows the names of the fields: + + index % time self children called name + ... + [2] 100.0 0.00 0.05 1 main [2] + 0.00 0.05 1/1 report [3] + + Here are the meanings of the fields in the subroutine-line for `main' +calling `report': + +`self' + An estimate of the amount of time spent directly within `report' + when `report' was called from `main'. + +`children' + An estimate of the amount of time spent in subroutines of `report' + when `report' was called from `main'. + + The sum of the `self' and `children' fields is an estimate of the + total time spent in calls to `report' from `main'. + +`called' + Two numbers, the number of calls to `report' from `main' followed + by the total number of non-recursive calls to `report'. This + ratio is used to determine how much of `report''s `self' and + `children' time gets credited to `main'. *Note Assumptions::. + +`name' + The name of the subroutine of `main' to which this line applies, + followed by the subroutine's index number. + + If the caller is part of a recursion cycle, the cycle number is + printed between the name and the index number. + + +File: gprof.info, Node: Cycles, Prev: Subroutines, Up: Call Graph + +How Mutually Recursive Functions Are Described +---------------------------------------------- + +The graph may be complicated by the presence of "cycles of recursion" +in the call graph. A cycle exists if a function calls another function +that (directly or indirectly) calls (or appears to call) the original +function. For example: if `a' calls `b', and `b' calls `a', then `a' +and `b' form a cycle. + + Whenever there are call paths both ways between a pair of functions, +they belong to the same cycle. If `a' and `b' call each other and `b' +and `c' call each other, all three make one cycle. Note that even if +`b' only calls `a' if it was not called from `a', `gprof' cannot +determine this, so `a' and `b' are still considered a cycle. + + The cycles are numbered with consecutive integers. When a function +belongs to a cycle, each time the function name appears in the call +graph it is followed by `<cycle NUMBER>'. + + The reason cycles matter is that they make the time values in the +call graph paradoxical. The "time spent in children" of `a' should +include the time spent in its subroutine `b' and in `b''s +subroutines--but one of `b''s subroutines is `a'! How much of `a''s +time should be included in the children of `a', when `a' is indirectly +recursive? + + The way `gprof' resolves this paradox is by creating a single entry +for the cycle as a whole. The primary line of this entry describes the +total time spent directly in the functions of the cycle. The +"subroutines" of the cycle are the individual functions of the cycle, +and all other functions that were called directly by them. The +"callers" of the cycle are the functions, outside the cycle, that +called functions in the cycle. + + Here is an example portion of a call graph which shows a cycle +containing functions `a' and `b'. The cycle was entered by a call to +`a' from `main'; both `a' and `b' called `c'. + + index % time self children called name + ---------------------------------------- + 1.77 0 1/1 main [2] + [3] 91.71 1.77 0 1+5 <cycle 1 as a whole> [3] + 1.02 0 3 b <cycle 1> [4] + 0.75 0 2 a <cycle 1> [5] + ---------------------------------------- + 3 a <cycle 1> [5] + [4] 52.85 1.02 0 0 b <cycle 1> [4] + 2 a <cycle 1> [5] + 0 0 3/6 c [6] + ---------------------------------------- + 1.77 0 1/1 main [2] + 2 b <cycle 1> [4] + [5] 38.86 0.75 0 1 a <cycle 1> [5] + 3 b <cycle 1> [4] + 0 0 3/6 c [6] + ---------------------------------------- + +(The entire call graph for this program contains in addition an entry +for `main', which calls `a', and an entry for `c', with callers `a' and +`b'.) + + index % time self children called name + <spontaneous> + [1] 100.00 0 1.93 0 start [1] + 0.16 1.77 1/1 main [2] + ---------------------------------------- + 0.16 1.77 1/1 start [1] + [2] 100.00 0.16 1.77 1 main [2] + 1.77 0 1/1 a <cycle 1> [5] + ---------------------------------------- + 1.77 0 1/1 main [2] + [3] 91.71 1.77 0 1+5 <cycle 1 as a whole> [3] + 1.02 0 3 b <cycle 1> [4] + 0.75 0 2 a <cycle 1> [5] + 0 0 6/6 c [6] + ---------------------------------------- + 3 a <cycle 1> [5] + [4] 52.85 1.02 0 0 b <cycle 1> [4] + 2 a <cycle 1> [5] + 0 0 3/6 c [6] + ---------------------------------------- + 1.77 0 1/1 main [2] + 2 b <cycle 1> [4] + [5] 38.86 0.75 0 1 a <cycle 1> [5] + 3 b <cycle 1> [4] + 0 0 3/6 c [6] + ---------------------------------------- + 0 0 3/6 b <cycle 1> [4] + 0 0 3/6 a <cycle 1> [5] + [6] 0.00 0 0 6 c [6] + ---------------------------------------- + + The `self' field of the cycle's primary line is the total time spent +in all the functions of the cycle. It equals the sum of the `self' +fields for the individual functions in the cycle, found in the entry in +the subroutine lines for these functions. + + The `children' fields of the cycle's primary line and subroutine +lines count only subroutines outside the cycle. Even though `a' calls +`b', the time spent in those calls to `b' is not counted in `a''s +`children' time. Thus, we do not encounter the problem of what to do +when the time in those calls to `b' includes indirect recursive calls +back to `a'. + + The `children' field of a caller-line in the cycle's entry estimates +the amount of time spent _in the whole cycle_, and its other +subroutines, on the times when that caller called a function in the +cycle. + + The `calls' field in the primary line for the cycle has two numbers: +first, the number of times functions in the cycle were called by +functions outside the cycle; second, the number of times they were +called by functions in the cycle (including times when a function in +the cycle calls itself). This is a generalization of the usual split +into non-recursive and recursive calls. + + The `calls' field of a subroutine-line for a cycle member in the +cycle's entry says how many time that function was called from +functions in the cycle. The total of all these is the second number in +the primary line's `calls' field. + + In the individual entry for a function in a cycle, the other +functions in the same cycle can appear as subroutines and as callers. +These lines show how many times each function in the cycle called or +was called from each other function in the cycle. The `self' and +`children' fields in these lines are blank because of the difficulty of +defining meanings for them when recursion is going on. + + +File: gprof.info, Node: Line-by-line, Next: Annotated Source, Prev: Call Graph, Up: Output + +Line-by-line Profiling +====================== + +`gprof''s `-l' option causes the program to perform "line-by-line" +profiling. In this mode, histogram samples are assigned not to +functions, but to individual lines of source code. The program usually +must be compiled with a `-g' option, in addition to `-pg', in order to +generate debugging symbols for tracking source code lines. + + The flat profile is the most useful output table in line-by-line +mode. The call graph isn't as useful as normal, since the current +version of `gprof' does not propagate call graph arcs from source code +lines to the enclosing function. The call graph does, however, show +each line of code that called each function, along with a count. + + Here is a section of `gprof''s output, without line-by-line +profiling. Note that `ct_init' accounted for four histogram hits, and +13327 calls to `init_block'. + + Flat profile: + + Each sample counts as 0.01 seconds. + % cumulative self self total + time seconds seconds calls us/call us/call name + 30.77 0.13 0.04 6335 6.31 6.31 ct_init + + + Call graph (explanation follows) + + + granularity: each sample hit covers 4 byte(s) for 7.69% of 0.13 seconds + + index % time self children called name + + 0.00 0.00 1/13496 name_too_long + 0.00 0.00 40/13496 deflate + 0.00 0.00 128/13496 deflate_fast + 0.00 0.00 13327/13496 ct_init + [7] 0.0 0.00 0.00 13496 init_block + + Now let's look at some of `gprof''s output from the same program run, +this time with line-by-line profiling enabled. Note that `ct_init''s +four histogram hits are broken down into four lines of source code - +one hit occurred on each of lines 349, 351, 382 and 385. In the call +graph, note how `ct_init''s 13327 calls to `init_block' are broken down +into one call from line 396, 3071 calls from line 384, 3730 calls from +line 385, and 6525 calls from 387. + + Flat profile: + + Each sample counts as 0.01 seconds. + % cumulative self + time seconds seconds calls name + 7.69 0.10 0.01 ct_init (trees.c:349) + 7.69 0.11 0.01 ct_init (trees.c:351) + 7.69 0.12 0.01 ct_init (trees.c:382) + 7.69 0.13 0.01 ct_init (trees.c:385) + + + Call graph (explanation follows) + + + granularity: each sample hit covers 4 byte(s) for 7.69% of 0.13 seconds + + % time self children called name + + 0.00 0.00 1/13496 name_too_long (gzip.c:1440) + 0.00 0.00 1/13496 deflate (deflate.c:763) + 0.00 0.00 1/13496 ct_init (trees.c:396) + 0.00 0.00 2/13496 deflate (deflate.c:727) + 0.00 0.00 4/13496 deflate (deflate.c:686) + 0.00 0.00 5/13496 deflate (deflate.c:675) + 0.00 0.00 12/13496 deflate (deflate.c:679) + 0.00 0.00 16/13496 deflate (deflate.c:730) + 0.00 0.00 128/13496 deflate_fast (deflate.c:654) + 0.00 0.00 3071/13496 ct_init (trees.c:384) + 0.00 0.00 3730/13496 ct_init (trees.c:385) + 0.00 0.00 6525/13496 ct_init (trees.c:387) + [6] 0.0 0.00 0.00 13496 init_block (trees.c:408) + + +File: gprof.info, Node: Annotated Source, Prev: Line-by-line, Up: Output + +The Annotated Source Listing +============================ + +`gprof''s `-A' option triggers an annotated source listing, which lists +the program's source code, each function labeled with the number of +times it was called. You may also need to specify the `-I' option, if +`gprof' can't find the source code files. + + Compiling with `gcc ... -g -pg -a' augments your program with +basic-block counting code, in addition to function counting code. This +enables `gprof' to determine how many times each line of code was +executed. For example, consider the following function, taken from +gzip, with line numbers added: + + 1 ulg updcrc(s, n) + 2 uch *s; + 3 unsigned n; + 4 { + 5 register ulg c; + 6 + 7 static ulg crc = (ulg)0xffffffffL; + 8 + 9 if (s == NULL) { + 10 c = 0xffffffffL; + 11 } else { + 12 c = crc; + 13 if (n) do { + 14 c = crc_32_tab[...]; + 15 } while (--n); + 16 } + 17 crc = c; + 18 return c ^ 0xffffffffL; + 19 } + + `updcrc' has at least five basic-blocks. One is the function +itself. The `if' statement on line 9 generates two more basic-blocks, +one for each branch of the `if'. A fourth basic-block results from the +`if' on line 13, and the contents of the `do' loop form the fifth +basic-block. The compiler may also generate additional basic-blocks to +handle various special cases. + + A program augmented for basic-block counting can be analyzed with +`gprof -l -A'. I also suggest use of the `-x' option, which ensures +that each line of code is labeled at least once. Here is `updcrc''s +annotated source listing for a sample `gzip' run: + + ulg updcrc(s, n) + uch *s; + unsigned n; + 2 ->{ + register ulg c; + + static ulg crc = (ulg)0xffffffffL; + + 2 -> if (s == NULL) { + 1 -> c = 0xffffffffL; + 1 -> } else { + 1 -> c = crc; + 1 -> if (n) do { + 26312 -> c = crc_32_tab[...]; + 26312,1,26311 -> } while (--n); + } + 2 -> crc = c; + 2 -> return c ^ 0xffffffffL; + 2 ->} + + In this example, the function was called twice, passing once through +each branch of the `if' statement. The body of the `do' loop was +executed a total of 26312 times. Note how the `while' statement is +annotated. It began execution 26312 times, once for each iteration +through the loop. One of those times (the last time) it exited, while +it branched back to the beginning of the loop 26311 times. + + +File: gprof.info, Node: Inaccuracy, Next: How do I?, Prev: Output, Up: Top + +Inaccuracy of `gprof' Output +**************************** + +* Menu: + +* Sampling Error:: Statistical margins of error +* Assumptions:: Estimating children times + + +File: gprof.info, Node: Sampling Error, Next: Assumptions, Up: Inaccuracy + +Statistical Sampling Error +========================== + +The run-time figures that `gprof' gives you are based on a sampling +process, so they are subject to statistical inaccuracy. If a function +runs only a small amount of time, so that on the average the sampling +process ought to catch that function in the act only once, there is a +pretty good chance it will actually find that function zero times, or +twice. + + By contrast, the number-of-calls and basic-block figures are derived +by counting, not sampling. They are completely accurate and will not +vary from run to run if your program is deterministic. + + The "sampling period" that is printed at the beginning of the flat +profile says how often samples are taken. The rule of thumb is that a +run-time figure is accurate if it is considerably bigger than the +sampling period. + + The actual amount of error can be predicted. For N samples, the +_expected_ error is the square-root of N. For example, if the sampling +period is 0.01 seconds and `foo''s run-time is 1 second, N is 100 +samples (1 second/0.01 seconds), sqrt(N) is 10 samples, so the expected +error in `foo''s run-time is 0.1 seconds (10*0.01 seconds), or ten +percent of the observed value. Again, if the sampling period is 0.01 +seconds and `bar''s run-time is 100 seconds, N is 10000 samples, +sqrt(N) is 100 samples, so the expected error in `bar''s run-time is 1 +second, or one percent of the observed value. It is likely to vary +this much _on the average_ from one profiling run to the next. +(_Sometimes_ it will vary more.) + + This does not mean that a small run-time figure is devoid of +information. If the program's _total_ run-time is large, a small +run-time for one function does tell you that that function used an +insignificant fraction of the whole program's time. Usually this means +it is not worth optimizing. + + One way to get more accuracy is to give your program more (but +similar) input data so it will take longer. Another way is to combine +the data from several runs, using the `-s' option of `gprof'. Here is +how: + + 1. Run your program once. + + 2. Issue the command `mv gmon.out gmon.sum'. + + 3. Run your program again, the same as before. + + 4. Merge the new data in `gmon.out' into `gmon.sum' with this command: + + gprof -s EXECUTABLE-FILE gmon.out gmon.sum + + 5. Repeat the last two steps as often as you wish. + + 6. Analyze the cumulative data using this command: + + gprof EXECUTABLE-FILE gmon.sum > OUTPUT-FILE + + +File: gprof.info, Node: Assumptions, Prev: Sampling Error, Up: Inaccuracy + +Estimating `children' Times +=========================== + +Some of the figures in the call graph are estimates--for example, the +`children' time values and all the time figures in caller and +subroutine lines. + + There is no direct information about these measurements in the +profile data itself. Instead, `gprof' estimates them by making an +assumption about your program that might or might not be true. + + The assumption made is that the average time spent in each call to +any function `foo' is not correlated with who called `foo'. If `foo' +used 5 seconds in all, and 2/5 of the calls to `foo' came from `a', +then `foo' contributes 2 seconds to `a''s `children' time, by +assumption. + + This assumption is usually true enough, but for some programs it is +far from true. Suppose that `foo' returns very quickly when its +argument is zero; suppose that `a' always passes zero as an argument, +while other callers of `foo' pass other arguments. In this program, +all the time spent in `foo' is in the calls from callers other than `a'. +But `gprof' has no way of knowing this; it will blindly and incorrectly +charge 2 seconds of time in `foo' to the children of `a'. + + We hope some day to put more complete data into `gmon.out', so that +this assumption is no longer needed, if we can figure out how. For the +nonce, the estimated figures are usually more useful than misleading. + + +File: gprof.info, Node: How do I?, Next: Incompatibilities, Prev: Inaccuracy, Up: Top + +Answers to Common Questions +*************************** + +How can I get more exact information about hot spots in my program? + Looking at the per-line call counts only tells part of the story. + Because `gprof' can only report call times and counts by function, + the best way to get finer-grained information on where the program + is spending its time is to re-factor large functions into sequences + of calls to smaller ones. Beware however that this can introduce + artifical hot spots since compiling with `-pg' adds a significant + overhead to function calls. An alternative solution is to use a + non-intrusive profiler, e.g. oprofile. + +How do I find which lines in my program were executed the most times? + Compile your program with basic-block counting enabled, run it, + then use the following pipeline: + + gprof -l -C OBJFILE | sort -k 3 -n -r + + This listing will show you the lines in your code executed most + often, but not necessarily those that consumed the most time. + +How do I find which lines in my program called a particular function? + Use `gprof -l' and lookup the function in the call graph. The + callers will be broken down by function and line number. + +How do I analyze a program that runs for less than a second? + Try using a shell script like this one: + + for i in `seq 1 100`; do + fastprog + mv gmon.out gmon.out.$i + done + + gprof -s fastprog gmon.out.* + + gprof fastprog gmon.sum + + If your program is completely deterministic, all the call counts + will be simple multiples of 100 (i.e. a function called once in + each run will appear with a call count of 100). + + + +File: gprof.info, Node: Incompatibilities, Next: Details, Prev: How do I?, Up: Top + +Incompatibilities with Unix `gprof' +*********************************** + +GNU `gprof' and Berkeley Unix `gprof' use the same data file +`gmon.out', and provide essentially the same information. But there +are a few differences. + + * GNU `gprof' uses a new, generalized file format with support for + basic-block execution counts and non-realtime histograms. A magic + cookie and version number allows `gprof' to easily identify new + style files. Old BSD-style files can still be read. *Note File + Format::. + + * For a recursive function, Unix `gprof' lists the function as a + parent and as a child, with a `calls' field that lists the number + of recursive calls. GNU `gprof' omits these lines and puts the + number of recursive calls in the primary line. + + * When a function is suppressed from the call graph with `-e', GNU + `gprof' still lists it as a subroutine of functions that call it. + + * GNU `gprof' accepts the `-k' with its argument in the form + `from/to', instead of `from to'. + + * In the annotated source listing, if there are multiple basic + blocks on the same line, GNU `gprof' prints all of their counts, + separated by commas. + + * The blurbs, field widths, and output formats are different. GNU + `gprof' prints blurbs after the tables, so that you can see the + tables without skipping the blurbs. + + +File: gprof.info, Node: Details, Next: GNU Free Documentation License, Prev: Incompatibilities, Up: Top + +Details of Profiling +******************** + +* Menu: + +* Implementation:: How a program collects profiling information +* File Format:: Format of `gmon.out' files +* Internals:: `gprof''s internal operation +* Debugging:: Using `gprof''s `-d' option + + +File: gprof.info, Node: Implementation, Next: File Format, Up: Details + +Implementation of Profiling +=========================== + +Profiling works by changing how every function in your program is +compiled so that when it is called, it will stash away some information +about where it was called from. From this, the profiler can figure out +what function called it, and can count how many times it was called. +This change is made by the compiler when your program is compiled with +the `-pg' option, which causes every function to call `mcount' (or +`_mcount', or `__mcount', depending on the OS and compiler) as one of +its first operations. + + The `mcount' routine, included in the profiling library, is +responsible for recording in an in-memory call graph table both its +parent routine (the child) and its parent's parent. This is typically +done by examining the stack frame to find both the address of the +child, and the return address in the original parent. Since this is a +very machine-dependent operation, `mcount' itself is typically a short +assembly-language stub routine that extracts the required information, +and then calls `__mcount_internal' (a normal C function) with two +arguments - `frompc' and `selfpc'. `__mcount_internal' is responsible +for maintaining the in-memory call graph, which records `frompc', +`selfpc', and the number of times each of these call arcs was traversed. + + GCC Version 2 provides a magical function +(`__builtin_return_address'), which allows a generic `mcount' function +to extract the required information from the stack frame. However, on +some architectures, most notably the SPARC, using this builtin can be +very computationally expensive, and an assembly language version of +`mcount' is used for performance reasons. + + Number-of-calls information for library routines is collected by +using a special version of the C library. The programs in it are the +same as in the usual C library, but they were compiled with `-pg'. If +you link your program with `gcc ... -pg', it automatically uses the +profiling version of the library. + + Profiling also involves watching your program as it runs, and +keeping a histogram of where the program counter happens to be every +now and then. Typically the program counter is looked at around 100 +times per second of run time, but the exact frequency may vary from +system to system. + + This is done is one of two ways. Most UNIX-like operating systems +provide a `profil()' system call, which registers a memory array with +the kernel, along with a scale factor that determines how the program's +address space maps into the array. Typical scaling values cause every +2 to 8 bytes of address space to map into a single array slot. On +every tick of the system clock (assuming the profiled program is +running), the value of the program counter is examined and the +corresponding slot in the memory array is incremented. Since this is +done in the kernel, which had to interrupt the process anyway to handle +the clock interrupt, very little additional system overhead is required. + + However, some operating systems, most notably Linux 2.0 (and +earlier), do not provide a `profil()' system call. On such a system, +arrangements are made for the kernel to periodically deliver a signal +to the process (typically via `setitimer()'), which then performs the +same operation of examining the program counter and incrementing a slot +in the memory array. Since this method requires a signal to be +delivered to user space every time a sample is taken, it uses +considerably more overhead than kernel-based profiling. Also, due to +the added delay required to deliver the signal, this method is less +accurate as well. + + A special startup routine allocates memory for the histogram and +either calls `profil()' or sets up a clock signal handler. This +routine (`monstartup') can be invoked in several ways. On Linux +systems, a special profiling startup file `gcrt0.o', which invokes +`monstartup' before `main', is used instead of the default `crt0.o'. +Use of this special startup file is one of the effects of using `gcc +... -pg' to link. On SPARC systems, no special startup files are used. +Rather, the `mcount' routine, when it is invoked for the first time +(typically when `main' is called), calls `monstartup'. + + If the compiler's `-a' option was used, basic-block counting is also +enabled. Each object file is then compiled with a static array of +counts, initially zero. In the executable code, every time a new +basic-block begins (i.e. when an `if' statement appears), an extra +instruction is inserted to increment the corresponding count in the +array. At compile time, a paired array was constructed that recorded +the starting address of each basic-block. Taken together, the two +arrays record the starting address of every basic-block, along with the +number of times it was executed. + + The profiling library also includes a function (`mcleanup') which is +typically registered using `atexit()' to be called as the program +exits, and is responsible for writing the file `gmon.out'. Profiling +is turned off, various headers are output, and the histogram is +written, followed by the call-graph arcs and the basic-block counts. + + The output from `gprof' gives no indication of parts of your program +that are limited by I/O or swapping bandwidth. This is because samples +of the program counter are taken at fixed intervals of the program's +run time. Therefore, the time measurements in `gprof' output say +nothing about time that your program was not running. For example, a +part of the program that creates so much data that it cannot all fit in +physical memory at once may run very slowly due to thrashing, but +`gprof' will say it uses little time. On the other hand, sampling by +run time has the advantage that the amount of load due to other users +won't directly affect the output you get. + + +File: gprof.info, Node: File Format, Next: Internals, Prev: Implementation, Up: Details + +Profiling Data File Format +========================== + +The old BSD-derived file format used for profile data does not contain a +magic cookie that allows to check whether a data file really is a +`gprof' file. Furthermore, it does not provide a version number, thus +rendering changes to the file format almost impossible. GNU `gprof' +uses a new file format that provides these features. For backward +compatibility, GNU `gprof' continues to support the old BSD-derived +format, but not all features are supported with it. For example, +basic-block execution counts cannot be accommodated by the old file +format. + + The new file format is defined in header file `gmon_out.h'. It +consists of a header containing the magic cookie and a version number, +as well as some spare bytes available for future extensions. All data +in a profile data file is in the native format of the target for which +the profile was collected. GNU `gprof' adapts automatically to the +byte-order in use. + + In the new file format, the header is followed by a sequence of +records. Currently, there are three different record types: histogram +records, call-graph arc records, and basic-block execution count +records. Each file can contain any number of each record type. When +reading a file, GNU `gprof' will ensure records of the same type are +compatible with each other and compute the union of all records. For +example, for basic-block execution counts, the union is simply the sum +of all execution counts for each basic-block. + +Histogram Records +----------------- + +Histogram records consist of a header that is followed by an array of +bins. The header contains the text-segment range that the histogram +spans, the size of the histogram in bytes (unlike in the old BSD +format, this does not include the size of the header), the rate of the +profiling clock, and the physical dimension that the bin counts +represent after being scaled by the profiling clock rate. The physical +dimension is specified in two parts: a long name of up to 15 characters +and a single character abbreviation. For example, a histogram +representing real-time would specify the long name as "seconds" and the +abbreviation as "s". This feature is useful for architectures that +support performance monitor hardware (which, fortunately, is becoming +increasingly common). For example, under DEC OSF/1, the "uprofile" +command can be used to produce a histogram of, say, instruction cache +misses. In this case, the dimension in the histogram header could be +set to "i-cache misses" and the abbreviation could be set to "1" +(because it is simply a count, not a physical dimension). Also, the +profiling rate would have to be set to 1 in this case. + + Histogram bins are 16-bit numbers and each bin represent an equal +amount of text-space. For example, if the text-segment is one thousand +bytes long and if there are ten bins in the histogram, each bin +represents one hundred bytes. + +Call-Graph Records +------------------ + +Call-graph records have a format that is identical to the one used in +the BSD-derived file format. It consists of an arc in the call graph +and a count indicating the number of times the arc was traversed during +program execution. Arcs are specified by a pair of addresses: the +first must be within caller's function and the second must be within +the callee's function. When performing profiling at the function +level, these addresses can point anywhere within the respective +function. However, when profiling at the line-level, it is better if +the addresses are as close to the call-site/entry-point as possible. +This will ensure that the line-level call-graph is able to identify +exactly which line of source code performed calls to a function. + +Basic-Block Execution Count Records +----------------------------------- + +Basic-block execution count records consist of a header followed by a +sequence of address/count pairs. The header simply specifies the +length of the sequence. In an address/count pair, the address +identifies a basic-block and the count specifies the number of times +that basic-block was executed. Any address within the basic-address can +be used. + + +File: gprof.info, Node: Internals, Next: Debugging, Prev: File Format, Up: Details + +`gprof''s Internal Operation +============================ + +Like most programs, `gprof' begins by processing its options. During +this stage, it may building its symspec list (`sym_ids.c:sym_id_add'), +if options are specified which use symspecs. `gprof' maintains a +single linked list of symspecs, which will eventually get turned into +12 symbol tables, organized into six include/exclude pairs - one pair +each for the flat profile (INCL_FLAT/EXCL_FLAT), the call graph arcs +(INCL_ARCS/EXCL_ARCS), printing in the call graph +(INCL_GRAPH/EXCL_GRAPH), timing propagation in the call graph +(INCL_TIME/EXCL_TIME), the annotated source listing +(INCL_ANNO/EXCL_ANNO), and the execution count listing +(INCL_EXEC/EXCL_EXEC). + + After option processing, `gprof' finishes building the symspec list +by adding all the symspecs in `default_excluded_list' to the exclude +lists EXCL_TIME and EXCL_GRAPH, and if line-by-line profiling is +specified, EXCL_FLAT as well. These default excludes are not added to +EXCL_ANNO, EXCL_ARCS, and EXCL_EXEC. + + Next, the BFD library is called to open the object file, verify that +it is an object file, and read its symbol table (`core.c:core_init'), +using `bfd_canonicalize_symtab' after mallocing an appropriately sized +array of symbols. At this point, function mappings are read (if the +`--file-ordering' option has been specified), and the core text space +is read into memory (if the `-c' option was given). + + `gprof''s own symbol table, an array of Sym structures, is now built. +This is done in one of two ways, by one of two routines, depending on +whether line-by-line profiling (`-l' option) has been enabled. For +normal profiling, the BFD canonical symbol table is scanned. For +line-by-line profiling, every text space address is examined, and a new +symbol table entry gets created every time the line number changes. In +either case, two passes are made through the symbol table - one to +count the size of the symbol table required, and the other to actually +read the symbols. In between the two passes, a single array of type +`Sym' is created of the appropriate length. Finally, +`symtab.c:symtab_finalize' is called to sort the symbol table and +remove duplicate entries (entries with the same memory address). + + The symbol table must be a contiguous array for two reasons. First, +the `qsort' library function (which sorts an array) will be used to +sort the symbol table. Also, the symbol lookup routine +(`symtab.c:sym_lookup'), which finds symbols based on memory address, +uses a binary search algorithm which requires the symbol table to be a +sorted array. Function symbols are indicated with an `is_func' flag. +Line number symbols have no special flags set. Additionally, a symbol +can have an `is_static' flag to indicate that it is a local symbol. + + With the symbol table read, the symspecs can now be translated into +Syms (`sym_ids.c:sym_id_parse'). Remember that a single symspec can +match multiple symbols. An array of symbol tables (`syms') is created, +each entry of which is a symbol table of Syms to be included or +excluded from a particular listing. The master symbol table and the +symspecs are examined by nested loops, and every symbol that matches a +symspec is inserted into the appropriate syms table. This is done +twice, once to count the size of each required symbol table, and again +to build the tables, which have been malloced between passes. From now +on, to determine whether a symbol is on an include or exclude symspec +list, `gprof' simply uses its standard symbol lookup routine on the +appropriate table in the `syms' array. + + Now the profile data file(s) themselves are read +(`gmon_io.c:gmon_out_read'), first by checking for a new-style +`gmon.out' header, then assuming this is an old-style BSD `gmon.out' if +the magic number test failed. + + New-style histogram records are read by `hist.c:hist_read_rec'. For +the first histogram record, allocate a memory array to hold all the +bins, and read them in. When multiple profile data files (or files +with multiple histogram records) are read, the starting address, ending +address, number of bins and sampling rate must match between the +various histograms, or a fatal error will result. If everything +matches, just sum the additional histograms into the existing in-memory +array. + + As each call graph record is read (`call_graph.c:cg_read_rec'), the +parent and child addresses are matched to symbol table entries, and a +call graph arc is created by `cg_arcs.c:arc_add', unless the arc fails +a symspec check against INCL_ARCS/EXCL_ARCS. As each arc is added, a +linked list is maintained of the parent's child arcs, and of the child's +parent arcs. Both the child's call count and the arc's call count are +incremented by the record's call count. + + Basic-block records are read (`basic_blocks.c:bb_read_rec'), but +only if line-by-line profiling has been selected. Each basic-block +address is matched to a corresponding line symbol in the symbol table, +and an entry made in the symbol's bb_addr and bb_calls arrays. Again, +if multiple basic-block records are present for the same address, the +call counts are cumulative. + + A gmon.sum file is dumped, if requested (`gmon_io.c:gmon_out_write'). + + If histograms were present in the data files, assign them to symbols +(`hist.c:hist_assign_samples') by iterating over all the sample bins +and assigning them to symbols. Since the symbol table is sorted in +order of ascending memory addresses, we can simple follow along in the +symbol table as we make our pass over the sample bins. This step +includes a symspec check against INCL_FLAT/EXCL_FLAT. Depending on the +histogram scale factor, a sample bin may span multiple symbols, in +which case a fraction of the sample count is allocated to each symbol, +proportional to the degree of overlap. This effect is rare for normal +profiling, but overlaps are more common during line-by-line profiling, +and can cause each of two adjacent lines to be credited with half a +hit, for example. + + If call graph data is present, `cg_arcs.c:cg_assemble' is called. +First, if `-c' was specified, a machine-dependent routine (`find_call') +scans through each symbol's machine code, looking for subroutine call +instructions, and adding them to the call graph with a zero call count. +A topological sort is performed by depth-first numbering all the +symbols (`cg_dfn.c:cg_dfn'), so that children are always numbered less +than their parents, then making a array of pointers into the symbol +table and sorting it into numerical order, which is reverse topological +order (children appear before parents). Cycles are also detected at +this point, all members of which are assigned the same topological +number. Two passes are now made through this sorted array of symbol +pointers. The first pass, from end to beginning (parents to children), +computes the fraction of child time to propagate to each parent and a +print flag. The print flag reflects symspec handling of +INCL_GRAPH/EXCL_GRAPH, with a parent's include or exclude (print or no +print) property being propagated to its children, unless they +themselves explicitly appear in INCL_GRAPH or EXCL_GRAPH. A second +pass, from beginning to end (children to parents) actually propagates +the timings along the call graph, subject to a check against +INCL_TIME/EXCL_TIME. With the print flag, fractions, and timings now +stored in the symbol structures, the topological sort array is now +discarded, and a new array of pointers is assembled, this time sorted +by propagated time. + + Finally, print the various outputs the user requested, which is now +fairly straightforward. The call graph (`cg_print.c:cg_print') and +flat profile (`hist.c:hist_print') are regurgitations of values already +computed. The annotated source listing +(`basic_blocks.c:print_annotated_source') uses basic-block information, +if present, to label each line of code with call counts, otherwise only +the function call counts are presented. + + The function ordering code is marginally well documented in the +source code itself (`cg_print.c'). Basically, the functions with the +most use and the most parents are placed first, followed by other +functions with the most use, followed by lower use functions, followed +by unused functions at the end. + + +File: gprof.info, Node: Debugging, Prev: Internals, Up: Details + +Debugging `gprof' +----------------- + +If `gprof' was compiled with debugging enabled, the `-d' option +triggers debugging output (to stdout) which can be helpful in +understanding its operation. The debugging number specified is +interpreted as a sum of the following options: + +2 - Topological sort + Monitor depth-first numbering of symbols during call graph analysis + +4 - Cycles + Shows symbols as they are identified as cycle heads + +16 - Tallying + As the call graph arcs are read, show each arc and how the total + calls to each function are tallied + +32 - Call graph arc sorting + Details sorting individual parents/children within each call graph + entry + +64 - Reading histogram and call graph records + Shows address ranges of histograms as they are read, and each call + graph arc + +128 - Symbol table + Reading, classifying, and sorting the symbol table from the object + file. For line-by-line profiling (`-l' option), also shows line + numbers being assigned to memory addresses. + +256 - Static call graph + Trace operation of `-c' option + +512 - Symbol table and arc table lookups + Detail operation of lookup routines + +1024 - Call graph propagation + Shows how function times are propagated along the call graph + +2048 - Basic-blocks + Shows basic-block records as they are read from profile data (only + meaningful with `-l' option) + +4096 - Symspecs + Shows symspec-to-symbol pattern matching operation + +8192 - Annotate source + Tracks operation of `-A' option + + +File: gprof.info, Node: GNU Free Documentation License, Prev: Details, Up: Top + +GNU Free Documentation License +****************************** + +GNU Free Documentation License + + Version 1.1, March 2000 + + Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple +Place, Suite 330, Boston, MA 02111-1307 USA + + Everyone is permitted to copy and distribute verbatim copies of +this license document, but changing it is not allowed. + + 0. PREAMBLE + + The purpose of this License is to make a manual, textbook, or other +written document "free" in the sense of freedom: to assure everyone the +effective freedom to copy and redistribute it, with or without +modifying it, either commercially or noncommercially. Secondarily, +this License preserves for the author and publisher a way to get credit +for their work, while not being considered responsible for +modifications made by others. + + This License is a kind of "copyleft", which means that derivative +works of the document must themselves be free in the same sense. It +complements the GNU General Public License, which is a copyleft license +designed for free software. + + We have designed this License in order to use it for manuals for free +software, because free software needs free documentation: a free +program should come with manuals providing the same freedoms that the +software does. But this License is not limited to software manuals; it +can be used for any textual work, regardless of subject matter or +whether it is published as a printed book. We recommend this License +principally for works whose purpose is instruction or reference. + + 1. APPLICABILITY AND DEFINITIONS + + This License applies to any manual or other work that contains a +notice placed by the copyright holder saying it can be distributed +under the terms of this License. The "Document", below, refers to any +such manual or work. Any member of the public is a licensee, and is +addressed as "you". + + A "Modified Version" of the Document means any work containing the +Document or a portion of it, either copied verbatim, or with +modifications and/or translated into another language. + + A "Secondary Section" is a named appendix or a front-matter section +of the Document that deals exclusively with the relationship of the +publishers or authors of the Document to the Document's overall subject +(or to related matters) and contains nothing that could fall directly +within that overall subject. (For example, if the Document is in part a +textbook of mathematics, a Secondary Section may not explain any +mathematics.) The relationship could be a matter of historical +connection with the subject or with related matters, or of legal, +commercial, philosophical, ethical or political position regarding them. + + The "Invariant Sections" are certain Secondary Sections whose titles +are designated, as being those of Invariant Sections, in the notice +that says that the Document is released under this License. + + The "Cover Texts" are certain short passages of text that are listed, +as Front-Cover Texts or Back-Cover Texts, in the notice that says that +the Document is released under this License. + + A "Transparent" copy of the Document means a machine-readable copy, +represented in a format whose specification is available to the general +public, whose contents can be viewed and edited directly and +straightforwardly with generic text editors or (for images composed of +pixels) generic paint programs or (for drawings) some widely available +drawing editor, and that is suitable for input to text formatters or +for automatic translation to a variety of formats suitable for input to +text formatters. A copy made in an otherwise Transparent file format +whose markup has been designed to thwart or discourage subsequent +modification by readers is not Transparent. A copy that is not +"Transparent" is called "Opaque". + + Examples of suitable formats for Transparent copies include plain +ASCII without markup, Texinfo input format, LaTeX input format, SGML or +XML using a publicly available DTD, and standard-conforming simple HTML +designed for human modification. Opaque formats include PostScript, +PDF, proprietary formats that can be read and edited only by +proprietary word processors, SGML or XML for which the DTD and/or +processing tools are not generally available, and the machine-generated +HTML produced by some word processors for output purposes only. + + The "Title Page" means, for a printed book, the title page itself, +plus such following pages as are needed to hold, legibly, the material +this License requires to appear in the title page. For works in +formats which do not have any title page as such, "Title Page" means +the text near the most prominent appearance of the work's title, +preceding the beginning of the body of the text. + + 2. VERBATIM COPYING + + You may copy and distribute the Document in any medium, either +commercially or noncommercially, provided that this License, the +copyright notices, and the license notice saying this License applies +to the Document are reproduced in all copies, and that you add no other +conditions whatsoever to those of this License. You may not use +technical measures to obstruct or control the reading or further +copying of the copies you make or distribute. However, you may accept +compensation in exchange for copies. If you distribute a large enough +number of copies you must also follow the conditions in section 3. + + You may also lend copies, under the same conditions stated above, and +you may publicly display copies. + + 3. COPYING IN QUANTITY + + If you publish printed copies of the Document numbering more than +100, and the Document's license notice requires Cover Texts, you must +enclose the copies in covers that carry, clearly and legibly, all these +Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts +on the back cover. Both covers must also clearly and legibly identify +you as the publisher of these copies. The front cover must present the +full title with all words of the title equally prominent and visible. +You may add other material on the covers in addition. Copying with +changes limited to the covers, as long as they preserve the title of +the Document and satisfy these conditions, can be treated as verbatim +copying in other respects. + + If the required texts for either cover are too voluminous to fit +legibly, you should put the first ones listed (as many as fit +reasonably) on the actual cover, and continue the rest onto adjacent +pages. + + If you publish or distribute Opaque copies of the Document numbering +more than 100, you must either include a machine-readable Transparent +copy along with each Opaque copy, or state in or with each Opaque copy +a publicly-accessible computer-network location containing a complete +Transparent copy of the Document, free of added material, which the +general network-using public has access to download anonymously at no +charge using public-standard network protocols. If you use the latter +option, you must take reasonably prudent steps, when you begin +distribution of Opaque copies in quantity, to ensure that this +Transparent copy will remain thus accessible at the stated location +until at least one year after the last time you distribute an Opaque +copy (directly or through your agents or retailers) of that edition to +the public. + + It is requested, but not required, that you contact the authors of +the Document well before redistributing any large number of copies, to +give them a chance to provide you with an updated version of the +Document. + + 4. MODIFICATIONS + + You may copy and distribute a Modified Version of the Document under +the conditions of sections 2 and 3 above, provided that you release the +Modified Version under precisely this License, with the Modified +Version filling the role of the Document, thus licensing distribution +and modification of the Modified Version to whoever possesses a copy of +it. In addition, you must do these things in the Modified Version: + + A. Use in the Title Page (and on the covers, if any) a title distinct + from that of the Document, and from those of previous versions +(which should, if there were any, be listed in the History section +of the Document). You may use the same title as a previous version +if the original publisher of that version gives permission. B. List on +the Title Page, as authors, one or more persons or entities +responsible for authorship of the modifications in the Modified +Version, together with at least five of the principal authors of the +Document (all of its principal authors, if it has less than five). C. +State on the Title page the name of the publisher of the Modified +Version, as the publisher. D. Preserve all the copyright notices of +the Document. E. Add an appropriate copyright notice for your +modifications adjacent to the other copyright notices. F. Include, +immediately after the copyright notices, a license notice giving the +public permission to use the Modified Version under the terms of +this License, in the form shown in the Addendum below. G. Preserve in +that license notice the full lists of Invariant Sections and +required Cover Texts given in the Document's license notice. H. +Include an unaltered copy of this License. I. Preserve the section +entitled "History", and its title, and add to it an item stating at +least the title, year, new authors, and publisher of the Modified +Version as given on the Title Page. If there is no section entitled +"History" in the Document, create one stating the title, year, +authors, and publisher of the Document as given on its Title Page, +then add an item describing the Modified Version as stated in the +previous sentence. J. Preserve the network location, if any, given in +the Document for public access to a Transparent copy of the +Document, and likewise the network locations given in the Document +for previous versions it was based on. These may be placed in the +"History" section. You may omit a network location for a work that +was published at least four years before the Document itself, or if +the original publisher of the version it refers to gives permission. +K. In any section entitled "Acknowledgements" or "Dedications", +preserve the section's title, and preserve in the section all the +substance and tone of each of the contributor acknowledgements +and/or dedications given therein. L. Preserve all the Invariant +Sections of the Document, unaltered in their text and in their +titles. Section numbers or the equivalent are not considered part +of the section titles. M. Delete any section entitled "Endorsements". +Such a section may not be included in the Modified Version. N. Do +not retitle any existing section as "Endorsements" or to conflict in +title with any Invariant Section. + + If the Modified Version includes new front-matter sections or +appendices that qualify as Secondary Sections and contain no material +copied from the Document, you may at your option designate some or all +of these sections as invariant. To do this, add their titles to the +list of Invariant Sections in the Modified Version's license notice. +These titles must be distinct from any other section titles. + + You may add a section entitled "Endorsements", provided it contains +nothing but endorsements of your Modified Version by various +parties-for example, statements of peer review or that the text has +been approved by an organization as the authoritative definition of a +standard. + + You may add a passage of up to five words as a Front-Cover Text, and +a passage of up to 25 words as a Back-Cover Text, to the end of the list +of Cover Texts in the Modified Version. Only one passage of +Front-Cover Text and one of Back-Cover Text may be added by (or through +arrangements made by) any one entity. If the Document already includes +a cover text for the same cover, previously added by you or by +arrangement made by the same entity you are acting on behalf of, you +may not add another; but you may replace the old one, on explicit +permission from the previous publisher that added the old one. + + The author(s) and publisher(s) of the Document do not by this License +give permission to use their names for publicity for or to assert or +imply endorsement of any Modified Version. + + 5. COMBINING DOCUMENTS + + You may combine the Document with other documents released under this +License, under the terms defined in section 4 above for modified +versions, provided that you include in the combination all of the +Invariant Sections of all of the original documents, unmodified, and +list them all as Invariant Sections of your combined work in its +license notice. + + The combined work need only contain one copy of this License, and +multiple identical Invariant Sections may be replaced with a single +copy. If there are multiple Invariant Sections with the same name but +different contents, make the title of each such section unique by +adding at the end of it, in parentheses, the name of the original +author or publisher of that section if known, or else a unique number. +Make the same adjustment to the section titles in the list of Invariant +Sections in the license notice of the combined work. + + In the combination, you must combine any sections entitled "History" +in the various original documents, forming one section entitled +"History"; likewise combine any sections entitled "Acknowledgements", +and any sections entitled "Dedications". You must delete all sections +entitled "Endorsements." + + 6. COLLECTIONS OF DOCUMENTS + + You may make a collection consisting of the Document and other +documents released under this License, and replace the individual +copies of this License in the various documents with a single copy that +is included in the collection, provided that you follow the rules of +this License for verbatim copying of each of the documents in all other +respects. + + You may extract a single document from such a collection, and +distribute it individually under this License, provided you insert a +copy of this License into the extracted document, and follow this +License in all other respects regarding verbatim copying of that +document. + + 7. AGGREGATION WITH INDEPENDENT WORKS + + A compilation of the Document or its derivatives with other separate +and independent documents or works, in or on a volume of a storage or +distribution medium, does not as a whole count as a Modified Version of +the Document, provided no compilation copyright is claimed for the +compilation. Such a compilation is called an "aggregate", and this +License does not apply to the other self-contained works thus compiled +with the Document, on account of their being thus compiled, if they are +not themselves derivative works of the Document. + + If the Cover Text requirement of section 3 is applicable to these +copies of the Document, then if the Document is less than one quarter +of the entire aggregate, the Document's Cover Texts may be placed on +covers that surround only the Document within the aggregate. Otherwise +they must appear on covers around the whole aggregate. + + 8. TRANSLATION + + Translation is considered a kind of modification, so you may +distribute translations of the Document under the terms of section 4. +Replacing Invariant Sections with translations requires special +permission from their copyright holders, but you may include +translations of some or all Invariant Sections in addition to the +original versions of these Invariant Sections. You may include a +translation of this License provided that you also include the original +English version of this License. In case of a disagreement between the +translation and the original English version of this License, the +original English version will prevail. + + 9. TERMINATION + + You may not copy, modify, sublicense, or distribute the Document +except as expressly provided for under this License. Any other attempt +to copy, modify, sublicense or distribute the Document is void, and will +automatically terminate your rights under this License. However, +parties who have received copies, or rights, from you under this +License will not have their licenses terminated so long as such parties +remain in full compliance. + + 10. FUTURE REVISIONS OF THIS LICENSE + + The Free Software Foundation may publish new, revised versions of +the GNU Free Documentation License from time to time. Such new +versions will be similar in spirit to the present version, but may +differ in detail to address new problems or concerns. See +http://www.gnu.org/copyleft/. + + Each version of the License is given a distinguishing version number. +If the Document specifies that a particular numbered version of this +License "or any later version" applies to it, you have the option of +following the terms and conditions either of that specified version or +of any later version that has been published (not as a draft) by the +Free Software Foundation. If the Document does not specify a version +number of this License, you may choose any version ever published (not +as a draft) by the Free Software Foundation. + + ADDENDUM: How to use this License for your documents + + To use this License in a document you have written, include a copy of +the License in the document and put the following copyright and license +notices just after the title page: + + Copyright (c) YEAR YOUR NAME. + Permission is granted to copy, distribute and/or modify this document + under the terms of the GNU Free Documentation License, Version 1.1 + or any later version published by the Free Software Foundation; + with the Invariant Sections being LIST THEIR TITLES, with the + Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. + A copy of the license is included in the section entitled "GNU + Free Documentation License". + + If you have no Invariant Sections, write "with no Invariant Sections" +instead of saying which ones are invariant. If you have no Front-Cover +Texts, write "no Front-Cover Texts" instead of "Front-Cover Texts being +LIST"; likewise for Back-Cover Texts. + + If your document contains nontrivial examples of program code, we +recommend releasing these examples in parallel under your choice of +free software license, such as the GNU General Public License, to +permit their use in free software. + + Tag Table: -(Indirect) -Node: Top707 -Node: Introduction1949 +Node: Top713 +Node: Introduction1952 Node: Compiling4278 -Node: Executing6939 -Node: Invoking9729 -Node: Output Options11143 -Node: Analysis Options17955 -Node: Miscellaneous Options21148 -Node: Deprecated Options22309 -Node: Symspecs24379 -Node: Output26200 -Node: Flat Profile27225 -Node: Call Graph32155 -Node: Primary35370 -Node: Callers37902 -Node: Subroutines40010 -Node: Cycles41810 -Node: Line-by-line48575 -Node: Annotated Source52374 -Node: Inaccuracy55235 -Node: Sampling Error55489 -Node: Assumptions58054 -Node: How do I?59522 -Node: Incompatibilities60740 -Node: Details62207 -Node: Implementation62596 -Node: File Format68488 -Node: Internals72746 -Node: Debugging81116 -Node: GNU Free Documentation License82712 +Node: Executing8502 +Node: Invoking11290 +Node: Output Options12701 +Node: Analysis Options19510 +Node: Miscellaneous Options22704 +Node: Deprecated Options23866 +Node: Symspecs25937 +Node: Output27755 +Node: Flat Profile28777 +Node: Call Graph33704 +Node: Primary36916 +Node: Callers39445 +Node: Subroutines41550 +Node: Cycles43347 +Node: Line-by-line50109 +Node: Annotated Source53905 +Node: Inaccuracy56763 +Node: Sampling Error57017 +Node: Assumptions59579 +Node: How do I?61040 +Node: Incompatibilities62872 +Node: Details64336 +Node: Implementation64725 +Node: File Format70614 +Node: Internals74860 +Node: Debugging83229 +Node: GNU Free Documentation License84822 End Tag Table |
