--- /dev/null
+This is configure.info, produced by makeinfo version 4.8 from
+.././etc/configure.texi.
+
+INFO-DIR-SECTION GNU admin
+START-INFO-DIR-ENTRY
+* configure: (configure). The GNU configure and build system
+END-INFO-DIR-ENTRY
+
+ This file documents the GNU configure and build system.
+
+ Copyright (C) 1998 Cygnus Solutions.
+
+ Permission is granted to make and distribute verbatim copies of this
+manual provided the copyright notice and this permission notice are
+preserved on all copies.
+
+ Permission is granted to copy and distribute modified versions of
+this manual under the conditions for verbatim copying, provided that
+the entire resulting derived work is distributed under the terms of a
+permission notice identical to this one.
+
+ Permission is granted to copy and distribute translations of this
+manual into another language, under the above conditions for modified
+versions, except that this permission notice may be stated in a
+translation approved by the Foundation.
+
+\1f
+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.
+
+\1f
+File: configure.info, Node: Introduction, Next: Getting Started, Prev: Top, Up: Top
+
+1 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.
+
+\1f
+File: configure.info, Node: Goals, Next: Tools, Up: Introduction
+
+1.1 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.
+
+\1f
+File: configure.info, Node: Tools, Next: History, Prev: Goals, Up: Introduction
+
+1.2 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.
+
+\1f
+File: configure.info, Node: History, Next: Building, Prev: Tools, Up: Introduction
+
+1.3 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.
+
+\1f
+File: configure.info, Node: Building, Prev: History, Up: Introduction
+
+1.4 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'. The equivalent html files are
+also built and installed in a separate step. To build the html files,
+run `make html'. To install the html files run `make install-html'.
+
+ 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.
+
+\1f
+File: configure.info, Node: Getting Started, Next: Files, Prev: Introduction, Up: Top
+
+2 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.
+
+\1f
+File: configure.info, Node: Write configure.in, Next: Write Makefile.am, Up: Getting Started
+
+2.1 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.
+
+\1f
+File: configure.info, Node: Write Makefile.am, Next: Write acconfig.h, Prev: Write configure.in, Up: Getting Started
+
+2.2 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.
+
+\1f
+File: configure.info, Node: Write acconfig.h, Next: Generate files, Prev: Write Makefile.am, Up: Getting Started
+
+2.3 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).
+
+\1f
+File: configure.info, Node: Generate files, Next: Getting Started Example, Prev: Write acconfig.h, Up: Getting Started
+
+2.4 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.
+
+\1f
+File: configure.info, Node: Getting Started Example, Prev: Generate files, Up: Getting Started
+
+2.5 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.
+
+\1f
+File: configure.info, Node: Getting Started Example 1, Next: Getting Started Example 2, Up: Getting Started Example
+
+2.5.1 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.
+
+\1f
+File: configure.info, Node: Getting Started Example 2, Next: Getting Started Example 3, Prev: Getting Started Example 1, Up: Getting Started Example
+
+2.5.2 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.
+
+\1f
+File: configure.info, Node: Getting Started Example 3, Next: Generate Files in Example, Prev: Getting Started Example 2, Up: Getting Started Example
+
+2.5.3 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
+
+\1f
+File: configure.info, Node: Generate Files in Example, Prev: Getting Started Example 3, Up: Getting Started Example
+
+2.5.4 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'
+
+\1f
+File: configure.info, Node: Files, Next: Configuration Names, Prev: Getting Started, Up: Top
+
+3 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.
+
+\1f
+File: configure.info, Node: Developer Files, Next: Build Files, Up: Files
+
+3.1 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.
+
+\1f
+File: configure.info, Node: Developer Files Picture, Next: Written Developer Files, Up: Developer Files
+
+3.1.1 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).
+
+ acconfig.h configure.in Makefile.am
+ | | |
+ | --------------+---------------------- |
+ | | | | |
+ v v | acinclude.m4 | |
+ *autoheader* | | v v
+ | | v --->*automake*
+ v |--->*aclocal* | |
+ config.in | | | v
+ | v | Makefile.in
+ | aclocal.m4---
+ | |
+ v v
+ *autoconf*
+ |
+ v
+ configure
+
+\1f
+File: configure.info, Node: Written Developer Files, Next: Generated Developer Files, Prev: Developer Files Picture, Up: Developer Files
+
+3.1.2 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.
+
+\1f
+File: configure.info, Node: Generated Developer Files, Prev: Written Developer Files, Up: Developer Files
+
+3.1.3 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'.
+
+\1f
+File: configure.info, Node: Build Files, Next: Support Files, Prev: Developer Files, Up: Files
+
+3.2 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.
+
+\1f
+File: configure.info, Node: Build Files Picture, Next: Build Files Description, Up: Build Files
+
+3.2.1 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.
+
+ config.in *configure* Makefile.in
+ | | |
+ | v |
+ | config.status |
+ | | |
+ *config.status*<======+==========>*config.status*
+ | |
+ v v
+ config.h Makefile
+
+\1f
+File: configure.info, Node: Build Files Description, Prev: Build Files Picture, Up: Build Files
+
+3.2.2 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'.
+
+\1f
+File: configure.info, Node: Support Files, Prev: Build Files, Up: Files
+
+3.3 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.
+
+\1f
+File: configure.info, Node: Configuration Names, Next: Cross Compilation Tools, Prev: Files, Up: Top
+
+4 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.
+
+\1f
+File: configure.info, Node: Configuration Name Definition, Next: Using Configuration Names, Up: Configuration Names
+
+4.1 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.
+
+\1f
+File: configure.info, Node: Using Configuration Names, Prev: Configuration Name Definition, Up: Configuration Names
+
+4.2 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*'.
+
+\1f
+File: configure.info, Node: Cross Compilation Tools, Next: Canadian Cross, Prev: Configuration Names, Up: Top
+
+5 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
+
+\1f
+File: configure.info, Node: Cross Compilation Concepts, Next: Host and Target, Up: Cross Compilation Tools
+
+5.1 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.
+
+\1f
+File: configure.info, Node: Host and Target, Next: Using the Host Type, Prev: Cross Compilation Concepts, Up: Cross Compilation Tools
+
+5.2 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.
+
+\1f
+File: configure.info, Node: Using the Host Type, Next: Specifying the Target, Prev: Host and Target, Up: Cross Compilation Tools
+
+5.3 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::.
+
+\1f
+File: configure.info, Node: Specifying the Target, Next: Using the Target Type, Prev: Using the Host Type, Up: Cross Compilation Tools
+
+5.4 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'.
+
+\1f
+File: configure.info, Node: Using the Target Type, Next: Cross Tools in the Cygnus Tree, Prev: Specifying the Target, Up: Cross Compilation Tools
+
+5.5 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'.
+
+\1f
+File: configure.info, Node: Cross Tools in the Cygnus Tree, Prev: Using the Target Type, Up: Cross Compilation Tools
+
+5.6 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
+
+\1f
+File: configure.info, Node: Host and Target Libraries, Next: Target Library Configure Scripts, Up: Cross Tools in the Cygnus Tree
+
+5.6.1 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.
+
+\1f
+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
+
+5.6.2 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.
+
+\1f
+File: configure.info, Node: Make Targets in Cygnus Tree, Next: Target libiberty, Prev: Target Library Configure Scripts, Up: Cross Tools in the Cygnus Tree
+
+5.6.3 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'.
+
+\1f
+File: configure.info, Node: Target libiberty, Prev: Make Targets in Cygnus Tree, Up: Cross Tools in the Cygnus Tree
+
+5.6.4 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.
+
+\1f
+File: configure.info, Node: Canadian Cross, Next: Cygnus Configure, Prev: Cross Compilation Tools, Up: Top
+
+6 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.
+
+\1f
+File: configure.info, Node: Canadian Cross Example, Next: Canadian Cross Concepts, Up: Canadian Cross
+
+6.1 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.
+
+\1f
+File: configure.info, Node: Canadian Cross Concepts, Next: Build Cross Host Tools, Prev: Canadian Cross Example, Up: Canadian Cross
+
+6.2 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.
+
+\1f
+File: configure.info, Node: Build Cross Host Tools, Next: Build and Host Options, Prev: Canadian Cross Concepts, Up: Canadian Cross
+
+6.3 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.
+
+\1f
+File: configure.info, Node: Build and Host Options, Next: CCross not in Cygnus Tree, Prev: Build Cross Host Tools, Up: Canadian Cross
+
+6.4 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.
+
+\1f
+File: configure.info, Node: CCross not in Cygnus Tree, Next: CCross in Cygnus Tree, Prev: Build and Host Options, Up: Canadian Cross
+
+6.5 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'.
+
+\1f
+File: configure.info, Node: CCross in Cygnus Tree, Next: Supporting Canadian Cross, Prev: CCross not in Cygnus Tree, Up: Canadian Cross
+
+6.6 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.
+
+\1f
+File: configure.info, Node: Standard Cygnus CCross, Next: Cross Cygnus CCross, Up: CCross in Cygnus Tree
+
+6.6.1 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'.
+
+\1f
+File: configure.info, Node: Cross Cygnus CCross, Prev: Standard Cygnus CCross, Up: CCross in Cygnus Tree
+
+6.6.2 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.
+
+\1f
+File: configure.info, Node: Supporting Canadian Cross, Prev: CCross in Cygnus Tree, Up: Canadian Cross
+
+6.7 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.
+
+\1f
+File: configure.info, Node: CCross in Configure, Next: CCross in Make, Up: Supporting Canadian Cross
+
+6.7.1 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.
+
+\1f
+File: configure.info, Node: CCross in Make, Prev: CCross in Configure, Up: Supporting Canadian Cross
+
+6.7.2 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'.
+
+\1f
+File: configure.info, Node: Cygnus Configure, Next: Multilibs, Prev: Canadian Cross, Up: Top
+
+7 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.
+
+\1f
+File: configure.info, Node: Cygnus Configure Basics, Next: Cygnus Configure in C++ Libraries, Up: Cygnus Configure
+
+7.1 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.
+
+\1f
+File: configure.info, Node: Cygnus Configure in C++ Libraries, Prev: Cygnus Configure Basics, Up: Cygnus Configure
+
+7.2 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'.
+
+\1f
+File: configure.info, Node: Multilibs, Next: FAQ, Prev: Cygnus Configure, Up: Top
+
+8 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.
+
+\1f
+File: configure.info, Node: Multilibs in gcc, Next: Multilibs in Target Libraries, Up: Multilibs
+
+8.1 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.
+
+\1f
+File: configure.info, Node: Multilibs in Target Libraries, Prev: Multilibs in gcc, Up: Multilibs
+
+8.2 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
+
+\1f
+File: configure.info, Node: FAQ, Next: Index, Prev: Multilibs, Up: Top
+
+9 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.
+
+\1f
+File: configure.info, Node: Index, Prev: FAQ, Up: Top
+
+Index
+*****
+
+\0\b[index\0\b]
+* Menu:
+
+* --build option: Build and Host Options.
+ (line 9)
+* --host option: Build and Host Options.
+ (line 14)
+* --target option: Specifying the Target.
+ (line 10)
+* _GNU_SOURCE: Write configure.in. (line 134)
+* AC_CANONICAL_HOST: Using the Host Type. (line 10)
+* AC_CANONICAL_SYSTEM: Using the Target Type.
+ (line 6)
+* AC_CONFIG_HEADER: Write configure.in. (line 66)
+* AC_EXEEXT: Write configure.in. (line 86)
+* AC_INIT: Write configure.in. (line 38)
+* AC_OUTPUT: Write configure.in. (line 142)
+* AC_PREREQ: Write configure.in. (line 42)
+* AC_PROG_CC: Write configure.in. (line 103)
+* AC_PROG_CXX: Write configure.in. (line 117)
+* acconfig.h: Written Developer Files.
+ (line 27)
+* acconfig.h, writing: Write acconfig.h. (line 6)
+* acinclude.m4: Written Developer Files.
+ (line 37)
+* aclocal.m4: Generated Developer Files.
+ (line 33)
+* AM_CONFIG_HEADER: Write configure.in. (line 53)
+* AM_DISABLE_SHARED: Write configure.in. (line 127)
+* AM_EXEEXT: Write configure.in. (line 86)
+* AM_INIT_AUTOMAKE: Write configure.in. (line 48)
+* AM_MAINTAINER_MODE: Write configure.in. (line 70)
+* AM_PROG_LIBTOOL: Write configure.in. (line 122)
+* AM_PROG_LIBTOOL in configure: FAQ. (line 19)
+* build option: Build and Host Options.
+ (line 9)
+* building with a cross compiler: Canadian Cross. (line 6)
+* canadian cross: Canadian Cross. (line 6)
+* canadian cross in configure: CCross in Configure. (line 6)
+* canadian cross in cygnus tree: CCross in Cygnus Tree.
+ (line 6)
+* canadian cross in makefile: CCross in Make. (line 6)
+* canadian cross, configuring: Build and Host Options.
+ (line 6)
+* canonical system names: Configuration Names. (line 6)
+* config.cache: Build Files Description.
+ (line 28)
+* config.h: Build Files Description.
+ (line 23)
+* config.h.in: Generated Developer Files.
+ (line 45)
+* config.in: Generated Developer Files.
+ (line 45)
+* config.status: Build Files Description.
+ (line 9)
+* config.status --recheck: FAQ. (line 40)
+* configuration names: Configuration Names. (line 6)
+* configuration triplets: Configuration Names. (line 6)
+* configure: Generated Developer Files.
+ (line 21)
+* configure build system: Build and Host Options.
+ (line 9)
+* configure host: Build and Host Options.
+ (line 14)
+* configure target: Specifying the Target.
+ (line 10)
+* configure.in: Written Developer Files.
+ (line 9)
+* configure.in, writing: Write configure.in. (line 6)
+* configuring a canadian cross: Build and Host Options.
+ (line 6)
+* cross compiler: Cross Compilation Concepts.
+ (line 6)
+* cross compiler, building with: Canadian Cross. (line 6)
+* cross tools: Cross Compilation Tools.
+ (line 6)
+* CY_GNU_GETTEXT in configure: FAQ. (line 19)
+* cygnus configure: Cygnus Configure. (line 6)
+* goals: Goals. (line 6)
+* history: History. (line 6)
+* host names: Configuration Names. (line 6)
+* host option: Build and Host Options.
+ (line 14)
+* host system: Host and Target. (line 6)
+* host triplets: Configuration Names. (line 6)
+* HOST_CC: CCross in Make. (line 27)
+* libg++ configure: Cygnus Configure in C++ Libraries.
+ (line 6)
+* libio configure: Cygnus Configure in C++ Libraries.
+ (line 6)
+* libstdc++ configure: Cygnus Configure in C++ Libraries.
+ (line 6)
+* Makefile: Build Files Description.
+ (line 18)
+* Makefile, garbage characters: FAQ. (line 29)
+* Makefile.am: Written Developer Files.
+ (line 18)
+* Makefile.am, writing: Write Makefile.am. (line 6)
+* Makefile.in: Generated Developer Files.
+ (line 26)
+* multilibs: Multilibs. (line 6)
+* stamp-h: Build Files Description.
+ (line 41)
+* stamp-h.in: Generated Developer Files.
+ (line 54)
+* system names: Configuration Names. (line 6)
+* system types: Configuration Names. (line 6)
+* target option: Specifying the Target.
+ (line 10)
+* target system: Host and Target. (line 6)
+* triplets: Configuration Names. (line 6)
+* undefined macros: FAQ. (line 12)
+
+
+\1f
+Tag Table:
+Node: Top\7f978
+Node: Introduction\7f1506
+Node: Goals\7f2588
+Node: Tools\7f3312
+Node: History\7f4306
+Node: Building\7f7304
+Node: Getting Started\7f10567
+Node: Write configure.in\7f11080
+Node: Write Makefile.am\7f18331
+Node: Write acconfig.h\7f21508
+Node: Generate files\7f23045
+Node: Getting Started Example\7f25011
+Node: Getting Started Example 1\7f25766
+Node: Getting Started Example 2\7f27687
+Node: Getting Started Example 3\7f30682
+Node: Generate Files in Example\7f33046
+Node: Files\7f34136
+Node: Developer Files\7f34747
+Node: Developer Files Picture\7f35127
+Node: Written Developer Files\7f36415
+Node: Generated Developer Files\7f38967
+Node: Build Files\7f42111
+Node: Build Files Picture\7f42772
+Node: Build Files Description\7f43536
+Node: Support Files\7f45542
+Node: Configuration Names\7f48424
+Node: Configuration Name Definition\7f48924
+Node: Using Configuration Names\7f51247
+Node: Cross Compilation Tools\7f53217
+Node: Cross Compilation Concepts\7f53908
+Node: Host and Target\7f54876
+Node: Using the Host Type\7f56377
+Node: Specifying the Target\7f57726
+Node: Using the Target Type\7f58515
+Node: Cross Tools in the Cygnus Tree\7f61946
+Node: Host and Target Libraries\7f63003
+Node: Target Library Configure Scripts\7f66752
+Node: Make Targets in Cygnus Tree\7f69844
+Node: Target libiberty\7f71192
+Node: Canadian Cross\7f72579
+Node: Canadian Cross Example\7f73420
+Node: Canadian Cross Concepts\7f74539
+Node: Build Cross Host Tools\7f76051
+Node: Build and Host Options\7f77003
+Node: CCross not in Cygnus Tree\7f78789
+Node: CCross in Cygnus Tree\7f79767
+Node: Standard Cygnus CCross\7f80188
+Node: Cross Cygnus CCross\7f81552
+Node: Supporting Canadian Cross\7f84352
+Node: CCross in Configure\7f84967
+Node: CCross in Make\7f88135
+Node: Cygnus Configure\7f89738
+Node: Cygnus Configure Basics\7f90573
+Node: Cygnus Configure in C++ Libraries\7f95251
+Node: Multilibs\7f96258
+Node: Multilibs in gcc\7f97303
+Node: Multilibs in Target Libraries\7f98381
+Node: FAQ\7f102572
+Node: Index\7f106672
+\1f
+End Tag Table
OSDN Git Service
