This file documents the GNU configure and build system.

Copyright (C) 1998 Cygnus Solutions.

Permission is granted to make and distribute verbatim copies ofthis manual provided the copyright notice and this permission noticeare preserved on all copies.

Permission is granted to copy and distribute modified versions of thismanual under the conditions for verbatim copying, provided that the entireresulting derived work is distributed under the terms of a permissionnotice identical to this one.

Permission is granted to copy and distribute translations of this manualinto another language, under the above conditions for modified versions,except that this permission notice may be stated in a translation approvedby the Foundation.

GNU configure and build system

The GNU configure and build system.

• 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.

1 Introduction

This document describes the GNU configure and build systems. Itdescribes how autoconf, automake, libtool, and make fit together. Italso 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 filesthe developer must write, which files are machine generated and how theyare generated, and where certain common problems should be addressed.

This document draws on several sources, includingthe autoconf manual by David MacKenzie,the automake manual by David MacKenzie and Tom Tromey,the libtool manual by Gordon Matzigkeit, and the Cygnus configure manual byK. Richard Pixley.

• Goals: Goals.
• Tools: The tools.
• History: History.
• Building: Building.

1.1 Goals

The GNU configure and build system has two main goals.

The first is to simplify the development of portable programs. Thesystem permits the developer to concentrate on writing the program,simplifying many details of portability across Unix and even Windowssystems, and permitting the developer to describe how to build theprogram using simple rules rather than complex Makefiles.

The second is to simplify the building of programs distributed as sourcecode. All programs are built using a simple, standardized, two stepprocess. The program builder need not install any special tools inorder to build the program.

1.2 Tools

The GNU configure and build system is comprised of several differenttools. Program developers must build and install all of these tools.

People who just want to build programs from distributed sources normallydo not need any special tools beyond a Unix shell, a make program, and aC compiler.

autoconf

provides a general portability framework, based on testing the featuresof the host system at build time.

automake

a system for describing how to build a program, permitting the developerto write a simplified Makefile.

libtool

a standardized approach to building shared libraries.

gettext

provides a framework for translation of text messages into otherlanguages; not really discussed in this document.

m4

autoconf requires the GNU version of m4; the standard Unix m4 does notsuffice.

perl

automake requires perl.

1.3 History

This is a very brief and probably inaccurate history.

As the number of Unix variants increased during the 1980s, it becameharder to write programs which could run on all variants. While it wasoften possible to use #ifdef to identify particular systems,developers frequently did not have access to every system, and thecharacteristics 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 RaphaelManfredi.
• The Cygnus configure script, by K. Richard Pixley, and the gcc configurescript, 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 allthe features of Cygnus configure. Since then, there has been a slow butsteady conversion of GNU programs from Cygnus configure to autoconf. gcchas been converted, eliminating the gcc configure script.

GNU autoconf was regularly maintained until late 1996. As of thiswriting in June, 1998, it has no public maintainer.

Most programs are built using the make program, which requires thedeveloper to write Makefiles describing how to build the programs. Since most programs are built in pretty much the same way, this led to alot of duplication.

The X Window system is built using the imake tool, which uses a databaseof rules to eliminate the duplication. However, building a tool whichwas developed using imake requires that the builder have imakeinstalled, 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, thisrequires that the builder install the new BSD make program.

In 1994, David MacKenzie wrote the first version of automake, whichpermitted writing a simple build description which was converted into aMakefile which could be used by the standard make program. In 1995, TomTromey completely rewrote automake in Perl, and he continues to enhanceit.

Various free packages built libraries, and by around 1995 severalincluded support to build shared libraries on various platforms. However, there was no consistent approach. In early 1996, GordonMatzigkeit began working on libtool, which provided a standardizedapproach to building shared libraries. This was integrated intoautomake 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 meetthe GNU coding standards.

1.4 Building

Most readers of this document should already know how to build a tool byrunning configure and make. This section may serve as aquick introduction or reminder.

Building a tool is normally as simple as running configurefollowed by make. You should normally run configure froman empty directory, using some path to refer to the configurescript in the source directory. The directory in which you runconfigure is called the object directory.

In order to use a object directory which is different from the sourcedirectory, you must be using the GNU version of make, which hasthe required VPATH support. Despite this restriction, using adifferent object directory is highly recommended:

• It keeps the files generated during the build from cluttering up yoursources.
• It permits you to remove the built files by simply removing the entirebuild directory.
• It permits you to build from the same sources with several sets ofconfigure options simultaneously.

If you don't have GNU make, you will have to run configurein the source directory. All GNU packages should support this; inparticular, GNU packages should not assume the presence of GNUmake.

After running configure, you can build the tools by runningmake.

To install the tools, run make install. Installing the toolswill copy the programs and any required support files to theinstallation directory. The location of the installationdirectory is controlled by configure options, as described below.

In the Cygnus tree at present, the info files are built and installed asa separate step. To build them, run make info. To install them,run make install-info. The equivalent html files are also builtand installed in a separate step. To build the html files, runmake html. To install the html files run make install-html.

All configure scripts support a wide variety of options. Themost interesting ones are --with and --enable optionswhich are generally specific to particular tools. You can usually usethe --help option to get a list of interesting options for aparticular configure script.

The only generic options you are likely to use are the --prefixand --exec-prefix options. These options are used to specify theinstallation directory.

The directory named by the --prefix option will hold machineindependent files such as info files.

The directory named by the --exec-prefix option, which isnormally a subdirectory of the --prefix directory, will holdmachine 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 --prefixoption of /usr/cygnus/ release, where release is thename of the release, and to use a --exec-prefix option of/usr/cygnus/ release /H- host, where host is theconfiguration name of the host system (see Configuration Names).

Do not use either the source or the object directory as the installationdirectory. That will just lead to confusion.

2 Getting Started

To start using the GNU configure and build system with your softwarepackage, you must write three files, and you must run some tools tomanually generate additional files.

• 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.

2.1 Write configure.in

You must first write the file configure.in. This is an autoconfinput file, and the autoconf manual describes in detail what this fileshould look like.

You will write tests in your configure.in file to check forconditions that may change from one system to another, such as thepresence 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 isavailable, and to use some other function when it is not, you wouldcheck for this by putting AC_CHECK_FUNCS(gettimeofday) inconfigure.in.

When the configure script is run at build time, this will arrange todefine the preprocessor macro HAVE_GETTIMEOFDAY to the value 1 ifthe gettimeofday function is available, and to not define themacro 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 mayhelp identify potential portability problems, and hence configure teststhat you will want to use. See the autoscan documentation.

Another handy tool for an existing body of code is ifnames. Thiswill show you all the preprocessor conditionals that the code alreadyuses. See the ifnames documentation.

Besides the portability tests which are specific to your particularpackage, every configure.in file should contain the followingmacros.

AC_INIT

This macro takes a single argument, which is the name of a file in yourpackage. For example, AC_INIT(foo.c).

AC_PREREQ( VERSION )

This macro is optional. It may be used to indicate the version ofautoconf that you are using. This will prevent users fromrunning an earlier version of autoconf and perhaps getting aninvalid configure script. For example, AC_PREREQ(2.12).

AM_INIT_AUTOMAKE

This macro takes two arguments: the name of the package, and a versionnumber. For example, AM_INIT_AUTOMAKE(foo, 1.0). (This macro isnot needed if you are not using automake).

AM_CONFIG_HEADER

This macro names the header file which will hold the preprocessor macrodefinitions at run time. Normally this should be config.h. Yoursources would then use #include "config.h" to include it.

This macro may optionally name the input file for that header file; bydefault, this is config.h.in, but that file name works poorly onDOS filesystems. Therefore, it is often better to name it explicitly asconfig.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 thanAM_CONFIG_HEADER).

AM_MAINTAINER_MODE

This macro always appears in Cygnus configure scripts. Other programsmay or may not use it.

If this macro is used, the --enable-maintainer-mode option isrequired to enable automatic rebuilding of generated files used by theconfigure 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 berebuilt automatically. This will cause problems if the wrong versionsof 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 configurefiles. Other programs may or may not use one of them.

This macro looks for the executable suffix used on the host system. OnUnix systems, this is the empty string. On Windows systems, this is.exe. This macro directs automake to use the executable suffixas appropriate when creating programs. This macro does not take anyarguments.

The AC_EXEEXT form is new, and is part of a Cygnus patch toautoconf to support compiling with Visual C++. Older programs useAM_EXEEXT instead.

(Programs which do not use automake use neither AC_EXEEXT norAM_EXEEXT).

AC_PROG_CC

If you are writing C code, you will normally want to use this macro. Itlocates the C compiler to use. It does not take any arguments.

However, if this configure.in file is for a library which is tobe compiled by a cross compiler which may not fully work, then you willnot want to use AC_PROG_CC. Instead, you will want to use avariant which does not call the macro AC_PROG_CC_WORKS. Examplescan be found in various configure.in files for libraries that arecompiled with cross compilers, such as libiberty or libgloss. This isessentially a bug in autoconf, and there will probably be a betterworkaround at some point.

AC_PROG_CXX

If you are writing C++ code, you will want to use this macro. Itlocates the C++ compiler to use. It does not take any arguments. Thesame 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 beshared, or you want to link against libraries which were built usinglibtool, then you will need this macro. This macro is required in orderto use libtool.

By default, this will cause all libraries to be built as sharedlibraries. To prevent this–to change the default–useAM_DISABLE_SHARED before AM_PROG_LIBTOOL. The configureoptions --enable-shared and --disable-shared may be usedto override the default at build time.

AC_DEFINE(_GNU_SOURCE)

GNU packages should normally include this line before any other featuretests. This defines the macro _GNU_SOURCE when compiling, whichdirects the libc header files to provide the standard GNU systeminterfaces 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 shouldproduce. This is normally a list of one or more Makefile filesin different directories. If your package lives entirely in a singledirectory, you would use simply AC_OUTPUT(Makefile). If you alsohave, for example, a lib subdirectory, you would useAC_OUTPUT(Makefile lib/Makefile).

If you want to use locally defined macros in your configure.infile, then you will need to write a acinclude.m4 file whichdefines them (if not using automake, this file is calledaclocal.m4). Alternatively, you can put separate macros in anm4 subdirectory, and put ACLOCAL_AMFLAGS = -I m4 in yourMakefile.am file so that the aclocal program will be ableto find them.

The different macro prefixes indicate which tool defines the macro. Macros which start with AC_ are part of autoconf. Macros whichstart with AM_ are provided by automake or libtool.

2.2 Write Makefile.am

You must write the file Makefile.am. This is an automake inputfile, and the automake manual describes in detail what this file shouldlook like.

The automake commands in Makefile.am mostly look like variableassignments in a Makefile. automake recognizes special variablenames, and automatically add make rules to the output as needed.

There will be one Makefile.am file for each directory in yourpackage. For each directory with subdirectories, the Makefile.amfile should contain the line

     SUBDIRS = dir
dir ...

where each dir is the name of a subdirectory.

For each Makefile.am, there should be a correspondingMakefile 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 fordetails.

You may to include the version number of automake that you areusing on the AUTOMAKE_OPTIONS line. For example,

     AUTOMAKE_OPTIONS = cygnus 1.3

This will prevent users from running an earlier version ofautomake and perhaps getting an invalid Makefile.in.

If your package builds a program, then in the directory where thatprogram is built you will normally want a line like

     bin_PROGRAMS = program

where program is the name of the program. You will then want aline like

program_SOURCES = file
file ...

where each file is the name of a source file to link into theprogram (e.g., foo.c).

If your package builds a library, and you do not want the library toever be built as a shared library, then in the directory where thatlibrary is built you will normally want a line like

     lib_LIBRARIES = libname.a

where lib name .a is the name of the library. You will thenwant a line like

     libname_a_SOURCES = file
file ...

where each file is the name of a source file to add to thelibrary.

If your package builds a library, and you want to permit building thelibrary as a shared library, then in the directory where that library isbuilt you will normally want a line like

     lib_LTLIBRARIES = libname.la

The use of LTLIBRARIES, and the .la extension, indicate alibrary to be built using libtool. As usual, you will then want a linelike

     libname_la_SOURCES = file
file ...

The strings bin and lib that appear above inbin_PROGRAMS and lib_LIBRARIES are not arbitrary. Theyrefer to particular directories, which may be set by the --bindirand --libdir options to configure. If those options arenot used, the default values are based on the --prefix or--exec-prefix options to configure. It is possible to useother names if the program or library should be installed in some otherdirectory.

The Makefile.am file may also contain almost anything that mayappear in a normal Makefile. automake also supports many otherspecial variables, as well as conditionals.

See the automake manual for more information.

2.3 Write acconfig.h

If you are generating a portability header file, (i.e., you are usingAM_CONFIG_HEADER in configure.in), then you will have towrite a acconfig.h file. It will have to contain the followinglines.

     /* Name of package.  */#undef PACKAGE/* Version of package.  */#undef VERSION

This requirement is really a bug in the system, and the requirement maybe eliminated at some later date.

The acconfig.h file will also similar comment and #undeflines for any unusual macros in the configure.in file, includingany macro which appears in a AC_DEFINE macro.

In particular, if you are writing a GNU package and therefore includeAC_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 suchrequirements by printing an error message when it is run. However, ifyou do anything particular odd in your configure.in file, youwill have to make sure that the right entries appear inacconfig.h, since otherwise the results of the tests may not beavailable in the config.h file which your code will use.

(Thee PACKAGE and VERSION lines are not required if youare not using automake, and in that case you may not need aacconfig.h file at all).

2.4 Generate files

Once you have written configure.in, Makefile.am,acconfig.h, and possibly acinclude.m4, you must useautoconf and automake programs to produce the first versions of thegenerated files. This is done by executing the following sequence ofcommands.

     aclocalautoconfautoheaderautomake

The aclocal and automake commands are part of the automakepackage, and the autoconf and autoheader commands are partof the autoconf package.

If you are using a m4 subdirectory for your macros, you will needto use the -I m4 option when you run aclocal.

If you are not using the Cygnus tree, use the -a option whenrunning automake command in order to copy the required supportfiles into your source directory.

If you are using libtool, you must build and install the libtool packagewith the same --prefix and --exec-prefix options as youused with the autoconf and automake packages. You must do this beforerunning any of the above commands. If you are not using the Cygnustree, you will need to run the libtoolize program to copy thelibtool 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 configurescript which will have been created by autoconf with the--enable-maintainer-mode option. This will give you a set ofMakefiles which will include rules to automatically rebuild all thegenerated files.

After doing that, whenever you have changed some of the input files andwant to regenerated the other files, go to your object directory and runmake. Doing this is more reliable than trying to rebuild thefiles manually, because there are complex order dependencies and it iseasy to forget something.

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 accesstimes of the file to the current time. We want this program to behighly portable.

We'll first see what this looks like without using autoconf andautomake, and then see what it looks like with them.

• Getting Started Example 1: First Try.
• Getting Started Example 2: Second Try.
• Getting Started Example 3: Third Try.
• Generate Files in Example: Generate Files.

2.5.1 First Try

Here is our first try at poke.c. Note that we've written itwithout 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>intmain (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 = gccCFLAGS = -g -O2all: pokepoke: 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 calldoes not accept a second argument of NULL. On those systems, weneed to pass a pointer to struct utimbuf structure. Unfortunately, even older systems don't define that structure; on thosesystems, we need to pass an array of two long values.

The header file stdlib.h was invented by ANSI C, and oldersystems don't have a copy. We included it above to get a declaration ofexit.

We can find some of these portability problems by runningautoscan, which will create a configure.scan file which wecan use as a prototype for our configure.in file. I won't showthe output, but it will notice the potential problems with utimeand 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 programwill need an install target. For that matter, we will also wanta clean target.

2.5.2 Second Try

Here is our second try at this program.

We modify poke.c to use preprocessor macros to control whatfeatures are available. (I've cheated a bit by using the same macronames 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_UTIMBUFstruct utimbuf{long actime;long modtime;};#endifstatic intutime_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  */intmain (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 thepreprocessor flags we use. We've also added install andclean 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_UTIMBUFCC = gccCFLAGS = -g -O2ALL_CFLAGS = $(STDC_HDRS) $(UTIME_H) $(UTIME_NULL) $(UTIMBUF) $(CFLAGS)all: pokepoke: poke.o$(CC) -o poke $(ALL_CFLAGS) $(LDFLAGS) poke.o.c.o:$(CC) -c $(ALL_CFLAGS) poke.cinstall: pokecp poke $(bindir)/pokeclean:rm poke poke.o

Some problems with this approach should be clear.

Users who want to compile poke will have to know how utime workson their systems, so that they can uncomment the Makefilecorrectly.

The installation is done using cp, but many systems have aninstall program which may be used, and which supports optionalfeatures such as stripping debugging information out of the installedbinary.

The use of Makefile variables like CC, CFLAGS andLDFLAGS follows the requirements of the GNU standards. This isconvenient for all packages, since it reduces surprises for users. However, it is easy to get the details wrong, and wind up with aslightly nonstandard distribution.

2.5.3 Third Try

For our third try at this program, we will write a configure.inscript to discover the configuration features on the host system, ratherthan requiring the user to edit the Makefile. We will also writea Makefile.am rather than a Makefile.

The only change to poke.c is to add a line at the start of thefile:

     #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_CCAC_HEADER_STDCAC_CHECK_HEADERS(utime.h)AC_EGREP_HEADER(utimbuf, utime.h, AC_DEFINE(HAVE_STRUCT_UTIMBUF))AC_FUNC_UTIME_NULLAC_OUTPUT(Makefile)

The first four macros in this file, and the last one, were describedabove; see Write configure.in. If we omit these macros, then whenwe 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 casechecking for utimbuf in utime.h.

AC_FUNC_UTIME_NULL

Check whether utime accepts a NULL second argument to set thefile 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 iscompared to our earlier Makefile.

     bin_PROGRAMS = pokepoke_SOURCES = poke.c

This means that we should build a single program name poke. Itshould be installed in the binary directory, which we calledbindir earlier. The program poke is built from the sourcefile poke.c.

We must also write a acconfig.h file. Besides PACKAGE andVERSION, which must be mentioned for all packages which useautomake, we must include HAVE_STRUCT_UTIMBUF, since we mentionedit in an AC_DEFINE.

     /* Name of package.  */#undef PACKAGE/* Version of package.  */#undef VERSION/* Whether utime.h defines struct utimbuf.  */#undef HAVE_STRUCT_UTIMBUF

2.5.4 Generate Files

We must now generate the other files, using the following commands.

     aclocalautoconfautoheaderautomake

When we run autoheader, it will remind us of any macros we forgotto add to acconfig.h.

When we run automake, it will want to add some files to ourdistribution. It will add them automatically if we use the--add-missing option.

By default, automake will run in GNU mode, which means that itwill want us to create certain additional files; as of this writing, itwill want NEWS, README, AUTHORS, andChangeLog, all of which are files which should appear in astandard GNU distribution. We can either add those files, or runautomake with the --foreign option.

Running these tools will generate the following files, all of which aredescribed in the next chapter.

• aclocal.m4
• configure
• config.in
• Makefile.in
• stamp-h.in

3 Files

As was seen in the previous chapter, the GNU configure and build systemuses 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.

• Developer Files: Developer Files.
• Build Files: Build Files.
• Support Files: Support Files.

3.1 Developer Files

This section describes the files written or generated by the developerof a package.

• Developer Files Picture: Developer Files Picture.
• Written Developer Files: Written Developer Files.
• Generated Developer Files: Generated Developer Files.

3.1.1 Developer Files Picture

Here is a picture of the files which are written by the developer, thegenerated files which would be included with a complete sourcedistribution, and the tools which create those files. The file names are in rectangles with square corners and the tool namesare in rectangles with rounded corners(e.g., autoheader is the name of a tool, not the name of a file).

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 ofautoconf macros. It may also contain ordinary shell script code. Thisfile will contain feature tests for portability issues. The last thingin the file will normally be an AC_OUTPUT macro listing whichfiles to create when the builder runs the configure script. This fileis always required when using the GNU configure system. See Write configure.in.

Makefile.am

This is the automake input file. It describes how the code should bebuilt. It consists of definitions of automake variables. It may alsocontain ordinary Makefile targets. This file is only needed when usingautomake (newer tools normally use automake, but there are still oldertools which have not been converted, in which the developer writesMakefile.in directly). See Write Makefile.am.

acconfig.h

When the configure script creates a portability header file, by usingAM_CONFIG_HEADER (or, if not using automake,AC_CONFIG_HEADER), this file is used to describe macros which arenot recognized by the autoheader command. This is normally afairly uninteresting file, consisting of a collection of #undeflines with comments. Normally any call to AC_DEFINE inconfigure.in will require a line in this file. See 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 needany local autoconf macros, then you don't need this file at all. Infact, in general, you never need local autoconf macros, since you canput everything in configure.in, but sometimes a local macro isconvenient.

Newer tools may omit acinclude.m4, and instead use asubdirectory, typically named m4, and defineACLOCAL_AMFLAGS = -I m4 in Makefile.am to forceaclocal to look there for macro definitions. The macrodefinitions are then placed in separate files in that directory.

The acinclude.m4 file is only used when using automake; in oldertools, the developer writes aclocal.m4 directly, if it is needed.

3.1.3 Generated Developer Files

The following files would be generated by the developer.

When using automake, these files are normally not generated manuallyafter the first time. Instead, the generated Makefile containsrules to automatically rebuild the files as required. WhenAM_MAINTAINER_MODE is used in configure.in (the normalcase in Cygnus code), the automatic rebuilding rules will only bedefined if you configure using the --enable-maintainer-modeoption.

When using automatic rebuilding, it is important to ensure that all thevarious tools have been built and installed on your PATH. Usingautomatic rebuilding is highly recommended, so much so that I'm notgoing 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 thepackage. This is generated by autoconf from configure.inand aclocal.m4. This is a shell script.

Makefile.in

This is the file which the configure script will turn into theMakefile at build time. This file is generated byautomake from Makefile.am. If you aren't using automake,you must write this file yourself. This file is pretty much a normalMakefile, with some configure substitutions for certainvariables.

aclocal.m4

This file is created by the aclocal program, based on thecontents of configure.in and acinclude.m4 (or, as noted inthe description of acinclude.m4 above, on the contents of anm4 subdirectory). This file contains definitions of autoconfmacros which autoconf will use when generating the fileconfigure. These autoconf macros may be defined by you inacinclude.m4 or they may be defined by other packages such asautomake, libtool or gettext. If you aren't using automake, you willnormally write this file yourself; in that case, if configure.inuses only standard autoconf macros, this file will not be needed at all.

config.in

This file is created by autoheader based on acconfig.h andconfigure.in. At build time, the configure script will definesome of the macros in it to create config.h, which may then beincluded by your program. This permits your C code to use preprocessorconditionals to change its behaviour based on the characteristics of thehost system. This file may also be called config.h.in.

stamp.h-in

This rather uninteresting file, which I omitted from the picture, isgenerated by automake. It always contains the stringtimestamp. It is used as a timestamp file indicating whetherconfig.in is up to date. Using a timestamp file means thatconfig.in can be marked as up to date without actually changingits modification time. This is useful since config.in dependsupon configure.in, but it is easy to change configure.inin a way which does not affect config.in.

3.2 Build Files

This section describes the files which are created at configure andbuild time. These are the files which somebody who builds the packagewill see.

Of course, the developer will also build the package. The distinctionbetween developer files and build files is not that the developer doesnot see the build files, but that somebody who only builds the packagedoes not have to worry about the developer files.

• Build Files Picture: Build Files Picture.
• Build Files Description: Build Files Description.

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 isrun to create other files, and the picture attempts to show that.

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 configurescript. The configure script will create the fileconfig.status, which is itself a shell script. When you firstrun configure, it will automatically run config.status. An Makefile derived from an automake generated Makefile.inwill contain rules to automatically run config.status again whennecessary to recreate certain files if their inputs change.

Makefile

This is the file which make will read to build the program. Theconfig.status script will transform Makefile.in intoMakefile.

config.h

This file defines C preprocessor macros which C code can use to adjustits behaviour on different systems. The config.status scriptwill transform config.in into config.h.

config.cache

This file did not fit neatly into the picture, and I omitted it. It isused by the configure script to cache results between runs. Thiscan be an important speedup. If you modify configure.in in sucha way that the results of old tests should change (perhaps you haveadded a new library to LDFLAGS), then you will have to removeconfig.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 tostamp-h.in. It is used as a timestamp file indicating whetherconfig.h is up to date. This is useful since config.hdepends upon config.status, but it is easy forconfig.status to change in a way which does not affectconfig.h.

3.3 Support Files

The GNU configure and build system requires several support files to beincluded with your distribution. You do not normally need to concernyourself with these. If you are using the Cygnus tree, most are alreadypresent. Otherwise, they will be installed with your source byautomake (with the --add-missing option) andlibtoolize.

You don't have to put the support files in the top level directory. Youcan put them in a subdirectory, and use the AC_CONFIG_AUX_DIRmacro in configure.in to tell automake and theconfigure script where they are.

In this section, I describe the support files, so that you can know whatthey are and why they are there.

ABOUT-NLS

Added by automake if you are using gettext. This is a documentationfile about the gettext project.

ansi2knr.c

Used by an automake generated Makefile if you put ansi2knrin AUTOMAKE_OPTIONS in Makefile.am. This permitscompiling 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 onwhich it is run.

config.sub

A shell script which canonicalizes a configuration name entered by auser.

elisp-comp

Used to compile Emacs LISP files.

install-sh

A shell script which installs a program. This is used if the configurescript can not find an install binary.

ltconfig

Used by libtool. This is a shell script which configures libtool forthe particular system on which it is used.

ltmain.sh

Used by libtool. This is the actual libtool script which is used, afterit is configured by ltconfig to build a library.

mdate-sh

A shell script used by an automake generated Makefile to prettyprint the modification time of a file. This is used to maintain versionnumbers for texinfo files.

missing

A shell script used if some tool is missing entirely. This is used byan automake generated Makefile to avoid certain sorts oftimestamp problems.

mkinstalldirs

A shell script which creates a directory, including all parentdirectories. This is used by an automake generated Makefileduring installation.

texinfo.tex

Required if you have any texinfo files. This is used when convertingTexinfo files into DVI using texi2dvi and TeX.

ylwrap

A shell script used by an automake generated Makefile to runprograms like bison, yacc, flex, and lex. These programs default to producing output files with a fixed name, andthe ylwrap script runs them in a subdirectory to avoid file nameconflicts when using a parallel make program.

4 Configuration Names

The GNU configure system names all systems using a configurationname. All such names used to be triplets (they may now contain fourparts in certain cases), and the term configuration triplet isstill seen.

• Configuration Name Definition: Configuration Name Definition.
• Using Configuration Names: Using Configuration Names.

4.1 Configuration Name Definition

This is a string of the formcpu-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 normallynot necessary to specify an entire name. In particular, themanufacturer field is often omitted, leading to strings such asi386-linux or sparc-sunos. The shell scriptconfig.sub will translate these shortened strings into thecanonical form. autoconf will arrange for config.sub to be runautomatically when it is needed.

The fields of a configuration name are as follows:

cpu

The type of processor. This is typically something like i386 orsparc. More specific variants are used as well, such asmipsel to indicate a little endian MIPS processor.

manufacturer

A somewhat freeform field which indicates the manufacturer of thesystem. This is often simply unknown. Other common strings arepc for an IBM PC compatible system, or the name of a workstationvendor, such as sun.

operating_system

The name of the operating system which is run on the system. This willbe something like solaris2.5 or irix6.3. There is noparticular restriction on the version number, and strings likeaix4.1.4.0 are seen. For an embedded system, which has nooperating system, this field normally indicates the type of object fileformat, such as elf or coff.

kernel

This is used mainly for GNU/Linux. A typical GNU/Linux configurationname 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 correctconfiguration name for the system on which it is run. It does byrunning uname and by examining other characteristics of thesystem.

Because config.guess can normally determine the configurationname for a machine, it is normally only necessary to specify aconfiguration name when building a cross-compiler or when building usinga cross-compiler.

4.2 Using Configuration Names

A configure script will sometimes have to make a decision based on aconfiguration name. You will need to do this if you have to compilecode differently based on something which can not be tested using astandard autoconf feature test.

It is normally better to test for particular features, rather than totest for a particular system. This is because as Unix evolves,different systems copy features from one another. Even if you need todetermine whether the feature is supported based on a configurationname, you should define a macro which describes the feature, rather thandefining a macro which describes the particular system you are on.

Testing for a particular system is normally done using a case statementin configure.in. The case statement might look something likethe following, assuming that host is a shell variable holding acanonical configuration name (which will be the case ifconfigure.in uses the AC_CANONICAL_HOST orAC_CANONICAL_SYSTEM macro).

     case "${host}" ini[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 systemfield, in order to match the version number which will be generated byconfig.guess.

In most cases you must be careful to match a range of processor types. For most processor families, a trailing * suffices, as inmips* above. For the i386 family, something along the lines ofi[3-7]86 suffices at present. For the m68k family, you willneed something like m68*. Of course, if you do not need to matchon the processor, it is simpler to just replace the entire field by a*, as in *-*-irix*.

5 Cross Compilation Tools

The GNU configure and build system can be used to build crosscompilation tools. A cross compilation tool is a tool which runs onone system and produces code which runs on another system.

• 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

5.1 Cross Compilation Concepts

A compiler which produces programs which run on a different system is across 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 samesystem as the one on which the compiler runs. When it is necessary todistinguish this case from the cross compilation case, such a compileris called a native compiler. Similarly, we speak of nativeassemblers, etc.

Although the debugger is not strictly speaking a compilation tool, it isnevertheless meaningful to speak of a cross debugger: a debugger whichis used to debug code which runs on another system. Everything that issaid below about configuring cross compilation tools applies to thedebugger as well.

5.2 Host and Target

When building cross compilation tools, there are two different systemsinvolved: the system on which the tools will run, and the system forwhich 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 targetsystem.

For example, suppose you have a compiler which runs on a GNU/Linuxsystem and generates ELF programs for a MIPS embedded system. In thiscase the GNU/Linux system is the host, and the MIPS ELF system is thetarget. Such a compiler could be called a GNU/Linux cross MIPS ELFcompiler, or, equivalently, a i386-linux-gnu crossmips-elf compiler.

Naturally, most programs are not cross compilation tools. For thoseprograms, it does not make sense to speak of a target. It only makessense to speak of a target for tools like gcc or thebinutils which actually produce running code. For example, itdoes not make sense to speak of the target of a tool like bisonor make.

Most cross compilation tools can also serve as native tools. For anative 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, fora GNU/Linux native compiler, the host is GNU/Linux, and the target isalso GNU/Linux.

5.3 Using the Host Type

In almost all cases the host system is the system on which you run theconfigure script, and on which you build the tools (for the casewhen they differ, see Canadian Cross).

If your configure script needs to know the configuration name of thehost system, and the package is not a cross compilation tool andtherefore does not have a target, put AC_CANONICAL_HOST inconfigure.in. This macro will arrange to define a few shellvariables when the configure script is run.

host

The canonical configuration name of the host. This will normally bedetermined by running the config.guess shell script, although theuser is permitted to override this by using an explicit --hostoption.

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, thiswill 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 inconfigure.in. For an example, see Using Configuration Names.

5.4 Specifying the Target

By default, the configure script will assume that the target isthe same as the host. This is the more common case; for example, itleads to a native compiler rather than a cross compiler.

If you want to build a cross compilation tool, you must specify thetarget explicitly by using the --target option when you runconfigure. The argument to --target is the configurationname of the system for which you wish to generate code. See Configuration Names.

For example, to build tools which generate code for a MIPS ELF embeddedsystem, you would use --target mips-elf.

5.5 Using the Target Type

When writing configure.in for a cross compilation tool, you willneed to use information about the target. To do this, putAC_CANONICAL_SYSTEM in configure.in.

AC_CANONICAL_SYSTEM will look for a --target option andcanonicalize it using the config.sub shell script. It will alsorun AC_CANONICAL_HOST (see Using the Host Type).

The target type will be recorded in the following shell variables. Notethat the host versions of these variables will also be defined byAC_CANONICAL_HOST.

target

The canonical configuration name of the target.

target_alias

The argument to the --target option. If the user did not specifya --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 canassume a native configuration. If they are different, you can assume across configuration.

It is arguably possible for host and target to representthe same system, but for the strings to not be identical. For example,if config.guess returns sparc-sun-sunos4.1.4, and somebodyconfigures with --target sparc-sun-sunos4.1, then the slightdifferences between the two versions of SunOS may be unimportant foryour tool. However, in the general case it can be quite difficult todetermine whether the differences between two configuration names aresignificant or not. Therefore, by convention, if the user specifies a--target option without specifying a --host option, it isassumed that the user wants to configure a cross compilation tool.

The variables target and target_alias should be handleddifferently.

In general, whenever the user may actually see a string,target_alias should be used. This includes anything which mayappear in the file system, such as a directory name or part of a toolname. It also includes any tool output, unless it is clearly labelledas the canonical target configuration name. This permits the user touse the --target option to specify how the tool will appear tothe outside world.

On the other hand, when checking for characteristics of the targetsystem, target should be used. This is because a wide variety of--target options may map into the same canonical configurationname. You should not attempt to duplicate the canonicalization done byconfig.sub in your own code.

By convention, cross tools are installed with a prefix of the argumentused with the --target option, also known as target_alias(see Using the Target Type). If the user does not use the--target option, and thus is building a native tool, no prefix isused.

For example, if gcc is configured with --target mips-elf, thenthe installed binary will be named mips-elf-gcc. If gcc isconfigured without a --target option, then the installed binarywill be named gcc.

The autoconf macro AC_ARG_PROGRAM will handle this for you. Ifyou are using automake, no more need be done; the programs willautomatically be installed with the correct prefixes. Otherwise, seethe autoconf documentation for AC_ARG_PROGRAM.

5.6 Cross Tools in the Cygnus Tree

The Cygnus tree is used for various packages including gdb, the GNUbinutils, and egcs. It is also, of course, used for Cygnus releases.

In the Cygnus tree, the top level configure script uses the oldCygnus configure system, not autoconf. The top level Makefile.inis written to build packages based on what is in the source tree, andsupports building a large number of tools in a singleconfigure/make step.

The Cygnus tree may be configured with a --target option. The--target option applies recursively to every subdirectory, andpermits building an entire set of cross tools at once.

• 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

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 programswhich run on the host, which is called the host compiler. This includeslibraries such as bfd and tcl. These libraries are builtwith the host compiler, and are linked into programs like the binutilsor gcc which run on the host.

Target libraries are built with the target compiler. If gcc is presentin the source tree, then the target compiler is the gcc that is builtusing the host compiler. Target libraries are libraries such asnewlib and libstdc++. These libraries are not linked intothe host programs, but are instead made available for use with programsbuilt with the target compiler.

For the rest of this section, assume that gcc is present in the sourcetree, so that it will be used to build the target libraries.

There is a complication here. The configure process needs to know whichcompiler you are going to use to build a tool; otherwise, the featuretests will not work correctly. The Cygnus tree handles this by notconfiguring the target libraries until the target compiler is built. Inorder to permit everything to build using a singleconfigure/make, the configuration of the target librariesis actually triggered during the make step.

When the target libraries are configured, the --target option isnot used. Instead, the --host option is used with the argumentof 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 theconfig.guess shell script. Any --build option is passeddown unchanged.

This translation of configuration options is done because since thetarget libraries are compiled with the target compiler, they are beingbuilt in order to run on the target of the overall configuration. Bythe definition of host, this means that their host system is the same asthe target system of the overall configuration.

The same process is used for both a native configuration and a crossconfiguration. Even when using a native configuration, the targetlibraries will be configured and built using the newly built compiler. This is particularly important for the C++ libraries, since there is noreason to assume that the C++ compiler used to build the host tools (ifthere even is one) uses the same ABI as the g++ compiler which will beused to build the target libraries.

There is one difference between a native configuration and a crossconfiguration. In a native configuration, the target libraries arenormally configured and built as siblings of the host tools. In a crossconfiguration, the target libraries are normally built in a subdirectorywhose name is the argument to --target. This is mainly forhistorical reasons.

To summarize, running configure in the Cygnus tree configures allthe host libraries and tools, but does not configure any of the targetlibraries. Running make then does the following steps:

• Build the host libraries.
• Build the host programs, including gcc. Note that we call gcc both ahost program (since it runs on the host) and a target compiler (since itgenerates 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 areactually controlled by Makefile targets.

5.6.2 Target Library Configure Scripts

There are a few things you must know in order to write a configurescript for a target library. This is just a quick sketch, and beginnersshouldn't worry if they don't follow everything here.

The target libraries are configured and built using a newly built targetcompiler. There may not be any startup files or libraries for thistarget compiler. In fact, those files will probably be built as part ofsome target library, which naturally means that they will not exist whenyour target library is configured.

This means that the configure script for a target library may not useany test which requires doing a link. This unfortunately includes manyuseful autoconf macros, such as AC_CHECK_FUNCS. autoconf macroswhich do a compile but not a link, such as AC_CHECK_HEADERS, maybe used.

This is a severe restriction, but normally not a fatal one, as targetlibraries can often assume the presence of other target libraries, andthus know which functions will be available.

As of this writing, the autoconf macro AC_PROG_CC does a link tomake sure that the compiler works. This may fail in a target library,so target libraries must use a different set of macros to locate thecompiler. See the configure.in file in a directory likelibiberty or libgloss for an example.

As noted in the previous section, target libraries are sometimes builtin directories which are siblings to the host tools, and are sometimesbuilt in a subdirectory. The --with-target-subdir configureoption will be passed when the library is configured. Its value will bean empty string if the target library is a sibling. Its value will bethe 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 configureused the --target option), then the library will be configuredwith the --with-cross-host option. The value of this option willbe the host system of the overall build. Recall that the host system ofthe library will be the target of the overall build. If the overallbuild is a native build, the --with-cross-host option will not beused.

A library which can be built both standalone and as a target library maywant to install itself into different directories depending upon thecase. When built standalone, or when built native, the library shouldbe installed in $(libdir). When built as a target library whichis not native, the library should be installed in $(tooldir)/lib. The --with-cross-host option may be used to distinguish thesecases.

This same test of --with-cross-host may be used to see whether itis OK to use link tests in the configure script. If the--with-cross-host option is not used, then the library is beingbuilt either standalone or native, and a link should work.

5.6.3 Make Targets in Cygnus Tree

The top level Makefile in the Cygnus tree defines targets forevery known subdirectory.

For every subdirectory dir which holds a host library or program,the Makefile target all- dir will build that libraryor program.

There are dependencies among host tools. For example, building gccrequires first building gas, because the gcc build process invokes thetarget assembler. These dependencies are reflected in the top levelMakefile.

For every subdirectory dir which holds a target library, theMakefile target configure-target- dir will configurethat library. The Makefile target all-target- dirwill build that library.

Every configure-target- dir target depends uponall-gcc, since gcc, the target compiler, is required to configurethe tool. Every all-target- dir target depends upon thecorresponding configure-target- dir target.

There are several other targets which may be of interest for eachdirectory: install- dir, clean- dir, andcheck- dir. There are also corresponding targetversions of these for the target libraries , such asinstall-target- dir.

5.6.4 Target libiberty

The libiberty subdirectory is currently a special case, in thatit is the only directory which is built both using the host compiler andusing the target compiler.

This is because the files in libiberty are used when building thehost tools, and they are also incorporated into the libstdc++target library as support code.

This duality does not pose any particular difficulties. It means thatthere are targets for both all-libiberty andall-target-libiberty.

In a native configuration, when target libraries are not built in asubdirectory, the same objects are normally used as both the host buildand the target build. This is normally OK, since libiberty containsonly C code, and in a native configuration the results of the hostcompiler and the target compiler are normally interoperable.

Irix 6 is again an exception here, since the SGI native compilerdefaults to using the O32 ABI, and gcc defaults to using theN32 ABI. On Irix 6, the target libraries are built in asubdirectory even for a native configuration, avoiding this problem.

There are currently no other libraries built for both the host and thetarget, but there is no conceptual problem with adding more.

6 Canadian Cross

It is possible to use the GNU configure and build system to build aprogram which will run on a system which is different from the system onwhich the tools are built. In other words, it is possible to buildprograms using a cross compiler.

This is referred to as a Canadian Cross.

• 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.

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 ona Solaris system. You would use a GNU/Linux cross Solaris compiler tobuild the program.

Of course, you could not run the resulting program on your GNU/Linuxsystem. You would have to copy it over to a Solaris system before youwould run it.

Of course, you could also simply build the programs on the Solarissystem in the first place. However, perhaps the Solaris system is notavailable for some reason; perhaps you actually don't have one, but youwant to build the tools for somebody else to use. Or perhaps yourGNU/Linux system is much faster than your Solaris system.

A Canadian Cross build is most frequently used when building programs torun on a non-Unix system, such as DOS or Windows. It may be simpler toconfigure and build on a Unix system than to support the configurationmachinery on a non-Unix system.

6.2 Canadian Cross Concepts

When building a Canadian Cross, there are at least two different systemsinvolved: the system on which the tools are being built, and the systemon which the tools will run.

The system on which the tools are being built is called the buildsystem.

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/Linuxsystem, 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 CanadianCross (i.e., build a cross compiler using a cross compiler). In thiscase, the system for which the resulting cross compiler generates codeis called the target system. (For a more complete discussion of hostand target systems, see Host and Target).

An example of building a cross compiler using a Canadian Cross would bebuilding a Windows cross MIPS ELF compiler on a GNU/Linux system. Inthis case the build system would be GNU/Linux, the host system would beWindows, and the target system would be MIPS ELF.

The name Canadian Cross comes from the case when the build, host, andtarget systems are all different. At the time that these issues wereall being hashed out, Canada had three national political parties.

6.3 Build Cross Host Tools

In order to configure a program for a Canadian Cross build, you mustfirst build and install the set of cross tools you will use to build theprogram.

These tools will be build cross host tools. That is, they will run onthe build system, and will produce code that runs on the host system.

It is easy to confuse the meaning of build and host here. Alwaysremember that the build system is where you are doing the build, and thehost system is where the resulting program will run. Therefore, youneed a build cross host compiler.

In general, you must have a complete cross environment in order to dothe build. This normally means a cross compiler, cross assembler, andso forth, as well as libraries and include files for the host system.

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 ofthe build system. This can normally be the result of running theconfig.guess shell script, and it is reasonable to use--build=`config.guess`.

The --host option is used to specify the configuration name ofthe host system.

As we explained earlier, config.guess is used to set the defaultvalue for the --host option (see Using the Host Type). Wecan now see that since config.guess returns the type of system onwhich it is run, it really identifies the build system. Since the hostsystem is normally the same as the build system (i.e., people do notnormally build using a cross compiler), it is reasonable to use theresult of config.guess as the default for the host system whenthe --host option is not used.

It might seem that if the --host option were used without the--build option that the configure script could runconfig.guess to determine the build system, and presume aCanadian Cross if the result of config.guess differed from the--host option. However, for historical reasons, some configurescripts are routinely run using an explicit --host option, ratherthan using the default from config.guess. As noted earlier, itis difficult or impossible to reliably compare configuration names(see 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.

6.5 Canadian Cross not in Cygnus Tree.

If you are not using the Cygnus tree, you must explicitly specify thecross tools which you want to use to build the program. This is done bysetting environment variables before running the configurescript.

You must normally set at least the environment variables CC,AR, and RANLIB to the cross tools which you want to use tobuild.

For some programs, you must set additional cross tools as well, such asAS, LD, or NM.

You would set these environment variables to the build cross tools whichyou are going to use.

For example, if you are building a Solaris program on a GNU/Linuxsystem, and your GNU/Linux cross Solaris compiler were namedsolaris-gcc, then you would set the environment variableCC to solaris-gcc.

6.6 Canadian Cross in Cygnus Tree

This section describes configuring and building a Canadian Cross whenusing the Cygnus tree.

• Standard Cygnus CCross: Building a Normal Program.
• Cross Cygnus CCross: Building a Cross Program.

6.6.1 Building a Normal Program

When configuring a Canadian Cross in the Cygnus tree, all theappropriate environment variables are automatically set tohost - 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 buildcross host tools. To see this, consider that when these cross toolswere built, they were configured to run on the build system and toproduce code for the host system. That is, they were configured with a--target option that is the same as the system which we are nowcalling the host. Recall that the default name for installed crosstools uses the target system as a prefix (see 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 defaultto using the compiler solaris-gcc. You must have previouslybuilt and installed this compiler, probably by doing a build with no--host option and with a --target option ofsolaris.

6.6.2 Building a Cross Program

There are additional considerations if you want to build a crosscompiler, rather than a native compiler, in the Cygnus tree using aCanadian Cross.

When you build a cross compiler using the Cygnus tree, then the targetlibraries will normally be built with the newly built target compiler(see Host and Target Libraries). However, this will not work whenbuilding with a Canadian Cross. This is because the newly built targetcompiler will be a program which runs on the host system, and thereforewill not be able to run on the build system.

Therefore, when building a cross compiler with the Cygnus tree, you mustfirst install a set of build cross target tools. These tools will beused when building the target libraries.

Note that this is not a requirement of a Canadian Cross in general. Forexample, it would be possible to build just the host cross target toolson the build system, to copy the tools to the host system, and to buildthe target libraries on the host system. The requirement for buildcross target tools is imposed by the Cygnus tree, which expects to beable to build both host programs and target libraries in a singleconfigure/make step. Because it builds these in a singlestep, it expects to be able to build the target libraries on the buildsystem, which means that it must use a build cross target toolchain.

For example, suppose you want to build a Windows cross MIPS ELF compileron a GNU/Linux system. You must have previously installed both aGNU/Linux cross Windows compiler and a GNU/Linux cross MIPS ELFcompiler.

In order to build the Windows (configuration name i386-cygwin32)cross MIPS ELF (configure name mips-elf) compiler, you mightexecute the following commands (long command lines are broken acrosslines with a trailing backslash as a continuation character).

     mkdir linux-x-cygwin32cd linux-x-cygwin32srcdir/configure --target i386-cygwin32 --prefix=installdir \--exec-prefix=installdir/H-i386-linuxmakemake installcd ..mkdir linux-x-mips-elfcd linux-x-mips-elfsrcdir/configure --target mips-elf --prefix=installdir \--exec-prefix=installdir/H-i386-linuxmakemake installcd ..mkdir cygwin32-x-mips-elfcd cygwin32-x-mips-elfsrcdir/configure --build=i386-linux-gnu --host=i386-cygwin32 \--target=mips-elf --prefix=wininstalldir \--exec-prefix=wininstalldir/H-i386-cygwin32makemake install

You would then copy the contents of wininstalldir over to theWindows machine, and run the resulting programs.

6.7 Supporting Canadian Cross

If you want to make it possible to build a program you are developingusing a Canadian Cross, you must take some care when writing yourconfigure and make rules. Simple cases will normally work correctly. However, it is not hard to write configure and make tests which willfail in a Canadian Cross.

• CCross in Configure: Supporting Canadian Cross in Configure Scripts.
• CCross in Make: Supporting Canadian Cross in Makefiles.

6.7.1 Supporting Canadian Cross in Configure Scripts

In a configure.in file, after calling AC_PROG_CC, you canfind out whether this is a Canadian Cross configure by examining theshell variable cross_compiling. In a Canadian Cross, which meansthat the compiler is a cross compiler, cross_compiling will beyes. In a normal configuration, cross_compiling will beno.

You ordinarily do not need to know the type of the build system in aconfigure script. However, if you do need that information, you can getit by using the macro AC_CANONICAL_SYSTEM, the same macro that isused to determine the target system. This macro will set the variablesbuild, build_alias, build_cpu, build_vendor,and build_os, which correspond to the similar target andhost variables, except that they describe the build system.

When writing tests in configure.in, you must remember that youwant to test the host environment, not the build environment.

Macros like AC_CHECK_FUNCS which use the compiler will test thehost environment. That is because the tests will be done by running thecompiler, which is actually a build cross host compiler. If thecompiler can find the function, that means that the function is presentin the host environment.

Tests like test -f /devlab/ptyp0, on the other hand, will test thebuild environment. Remember that the configure script is running on thebuild system, not the host system. If your configure scripts examinesfiles, those files will be on the build system. Whatever you determinebased 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 mainexception is AC_TRY_RUN. This macro tries to compile and run atest program. This will fail in a Canadian Cross, because the programwill be compiled for the host system, which means that it will not runon the build system.

The AC_TRY_RUN macro provides an optional argument to tell theconfigure script what to do in a Canadian Cross. If that argument isnot 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 workwith 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 youcan use the cross compiling argument to AC_TRY_RUN to tell yourprogram that the test could not be performed at configure time.

There are a few other autoconf macros which will not work correctly witha Canadian Cross: a partial list is AC_FUNC_GETPGRP,AC_FUNC_SETPGRP, AC_FUNC_SETVBUF_REVERSED, andAC_SYS_RESTARTABLE_SYSCALLS. The AC_CHECK_SIZEOF macro isgenerally not very useful with a Canadian Cross; it permits an optionalargument indicating the default size, but there is no way to know whatthe correct default should be.

6.7.2 Supporting Canadian Cross in Makefiles.

The main Canadian Cross issue in a Makefile arises when you wantto use a subsidiary program to generate code or data which you will theninclude in your real program.

If you compile this subsidiary program using $(CC) in the usualway, you will not be able to run it. This is because $(CC) willbuild a program for the host system, but the program is being built onthe build system.

You must instead use a compiler for the build system, rather than thehost 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 arecompiling with $(CC_FOR_BUILD). The configure script willbuild config.h with information for the host system. However,you are compiling the file using a compiler for the build system (anative compiler). Subsidiary programs are normally simple filters whichdo no user interaction, and it is normally possible to write them in ahighly portable fashion so that the absence of config.h is notcrucial.

The gcc Makefile.in shows a complex situation in which certainfiles, such as rtl.c, must be compiled into both subsidiaryprograms run on the build system and into the final program. Thisapproach may be of interest for advanced build system hackers. Notethat the build system compiler is rather confusingly calledHOST_CC.

7 Cygnus Configure

The Cygnus configure script predates autoconf. All of its interestingfeatures have been incorporated into autoconf. No new programs shouldbe written to use the Cygnus configure script.

However, the Cygnus configure script is still used in a few places: atthe top of the Cygnus tree and in a few target libraries in the Cygnustree. Until those uses have been replaced with autoconf, some briefnotes are appropriate here. This is not complete documentation, but itshould be possible to use this as a guide while examining the scriptsthemselves.

• Cygnus Configure Basics: Cygnus Configure Basics.
• Cygnus Configure in C++ Libraries: Cygnus Configure in C++ Libraries.

7.1 Cygnus Configure Basics

Cygnus configure does not use any generated files; there is no programcorresponding to autoconf. Instead, there is a single shellscript named configure which may be found at the top of theCygnus tree. This shell script was written by hand; it was notgenerated by autoconf, and it is incorrect, and indeed harmful, to runautoconf in the top level of a Cygnus tree.

Cygnus configure works in a particular directory by examining the fileconfigure.in in that directory. That file is broken into fourseparate shell scripts.

The first is the contents of configure.in up to a line thatstarts with # per-host:. This is the common part.

The second is the rest of configure.in up to a line that startswith # per-target:. This is the per host part.

The third is the rest of configure.in up to a line that startswith # post-target:. This is the per target part.

The fourth is the remainder of configure.in. This is the posttarget part.

If any of these comment lines are missing, the corresponding shellscript is empty.

Cygnus configure will first execute the common part. This must set theshell variable srctrigger to the name of a source file, toconfirm that Cygnus configure is looking at the right directory. Thismay set the shell variables package_makefile_frag andpackage_makefile_rules_frag.

Cygnus configure will next set the build and host shellvariables, and execute the per host part. This may set the shellvariable host_makefile_frag.

Cygnus configure will next set the target variable, and executethe per target part. This may set the shell variabletarget_makefile_frag.

Any of these scripts may set the subdirs shell variable. Thisvariable is a list of subdirectories where a Makefile.in file maybe found. Cygnus configure will automatically look for aMakefile.in file in the current directory. The subdirsshell variable is not normally used, and I believe that the onlydirectory which uses it at present is newlib.

For each Makefile.in, Cygnus configure will automatically createa Makefile by adding definitions for make variables suchas host and target, and automatically editing the valuesof make variables such as prefix if they are present.

Also, if any of the makefile_frag shell variables are set, Cygnusconfigure will interpret them as file names relative to either theworking directory or the source directory, and will read the contents ofthe file into the generated Makefile. The file contents will beread in after the first line in Makefile.in which starts with####.

These Makefile fragments are used to customize behaviour for aparticular host or target. They serve to select particular files tocompile, and to define particular preprocessor macros by providingvalues 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 autoconfAC_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 customizethe Makefile. When it is run, the shell variable Makefilewill hold the name of the Makefile, including the appropriatedirectory component.

Like an autoconf generated configure script, Cygnus configurewill create a file named config.status which, when run, willautomatically recreate the configuration. The config.status filewill simply execute the Cygnus configure script again with theappropriate arguments.

Any of the parts of configure.in may set the shell variablesfiles and links. Cygnus configure will set up symlinksfrom the names in links to the files named in files. Thisis similar to the autoconf AC_LINK_FILES macro.

Finally, any of the parts of configure.in may set the shellvariable configdirs to a set of subdirectories. If it is set,Cygnus configure will recursively run the configure process in eachsubdirectory. If the subdirectory uses Cygnus configure, it willcontain a configure.in file but no configure file, inwhich case Cygnus configure will invoke itself recursively. If thesubdirectory has a configure file, Cygnus configure assumes thatit is an autoconf generated configure script, and simply invokesit directly.

7.2 Cygnus Configure in C++ Libraries

The C++ library configure system, written by Per Bothner, deservesspecial mention. It uses Cygnus configure, but it does feature testinglike that done by autoconf generated configure scripts. Thisapproach is used in the libraries libio, libstdc++, andlibg++.

Most of the Makefile information is written out by the shellscript libio/config.shared. Each configure.in file setscertain shell variables, and then invokes config.shared to createtwo package Makefile fragments. These fragments are thenincorporated into the resulting Makefile by the Cygnus configurescript.

The file _G_config.h is created in the libio objectdirectory by running the shell script libio/gen-params. Thisshell script uses feature tests to define macros and typedefs in_G_config.h.

8 Multilibs

For some targets gcc may have different processor requirements dependingupon command line options. An obvious example is the-msoft-float option supported on several processors. This optionmeans that the floating point registers are not available, which meansthat floating point operations must be done by calling an emulationsubroutine rather than by using machine instructions.

For such options, gcc is often configured to compile target librariestwice: once with -msoft-float and once without. When gcccompiles target libraries more than once, the resulting libraries arecalled multilibs.

Multilibs are not really part of the GNU configure and build system, butwe discuss them here since they require support in the configurescripts and Makefiles used for target libraries.

• Multilibs in gcc: Multilibs in gcc.
• Multilibs in Target Libraries: Multilibs in Target Libraries.

8.1 Multilibs in gcc

In gcc, multilibs are defined by setting the variableMULTILIB_OPTIONS in the target Makefile fragment. Severalother MULTILIB variables may also be defined there. See The Target Makefile Fragment (Using and Porting GNU CC).Target Fragment - GNU Compiler Collection (GCC) Internals

If you have built gcc, you can see what multilibs it uses by running itwith the -print-multi-lib option. The output .; meansthat no multilibs are used. In general, the output is a sequence oflines, one per multilib. The first part of each line, up to the;, is the name of the multilib directory. The second part is alist 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 thedefault library to use when no special compiler options are used. Thesubdirectories of the tree hold versions of the library to use whenparticular compiler options are used.

8.2 Multilibs in Target Libraries

The target libraries in the Cygnus tree are automatically built withmultilibs. 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 configurewhen it is run for the target libraries (see Host and Target Libraries).

Each target library uses the shell script config-ml.in, writtenby Doug Evans, to prepare to build target libraries. This shell scriptis invoked after the Makefile has been created by theconfigure 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 foreach multilib in the appropriate subdirectory. When configuring in thesource directory (which is not recommended), it will build a symlinktree of the sources in each subdirectory.

The config-ml.in script sets several variables in the variousMakefiles. The Makefile.in must have definitions forthese variables already; config-ml.in simply changes the existingvalues. The Makefile should use default values for thesevariables 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 thesource 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 objectdirectory. The default value should be the empty string. This willdiffer from MULTISRCTOP when configuring in the source tree(which is not recommended).

MULTIDIRS

In the top level Makefile only, config-ml.in will set thisto the list of multilib subdirectories. The default value should be theempty string.

MULTISUBDIR

config-ml.in will set this to the installed subdirectory name touse for this subdirectory, with a leading /. The default valueshold be the empty string.

MULTIDO

MULTICLEAN

In the top level Makefile only, config-ml.in will setthese variables to commands to use when doing a recursive make. Thesevariables should both default to the string true, so that bydefault nothing happens.

All references to the parent of the source directory should use thevariable MULTISRCTOP. Instead of writing $(srcdir)/..,you must write $(srcdir)/$(MULTISRCTOP)...

Similarly, references to the parent of the object directory should usethe variable MULTIBUILDTOP.

In the installation target, the libraries should be installed in thesubdirectory MULTISUBDIR. Instead of installing$(libdir)/libfoo.a, install$(libdir)$(MULTISUBDIR)/libfoo.a.

The config-ml.in script also modifies the top levelMakefile to add multi-do and multi-clean targetswhich are used when building multilibs.

The default target of the Makefile should include the followingcommand:

     @$(MULTIDO) $(FLAGS_TO_PASS) DO=all multi-do

This assumes that $(FLAGS_TO_PASS) is defined as a set ofvariables to pass to a recursive invocation of make. This willbuild all the multilibs. Note that the default value of MULTIDOis true, so by default this command will do nothing. It willonly do something in the top level Makefile if multilibs wereenabled.

The install target of the Makefile should include thefollowing command:

     @$(MULTIDO) $(FLAGS_TO_PASS) DO=install multi-do

In general, any operation, other than clean, which should be performedon all the multilibs should use a $(MULTIDO) line, setting thevariable DO to the target of each recursive call to make.

The clean targets (clean, mostlyclean, etc.) shoulduse $(MULTICLEAN). For example, the clean target shoulddo this:

     @$(MULTICLEAN) DO=clean multi-clean

9 Frequently Asked Questions

Which do I run first, autoconf or automake?

Except when you first add autoconf or automake support to a package, youshouldn't run either by hand. Instead, configure with the--enable-maintainer-mode option, and let make take care ofit.

autoconf says something about undefined macros.

This means that you have macros in your configure.in which arenot defined by autoconf. You may be using an old version ofautoconf; try building and installing a newer one. Make sure thenewly 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 shouldbe defined in your aclocal.m4 file, but aren't. This usuallymeans that aclocal was not able to appropriate definitions of themacros. Make sure that you have installed all the packages you need. In particular, make sure that you have installed libtool (this is whereAM_PROG_LIBTOOL is defined) and gettext (this is whereCY_GNU_GETTEXT is defined, at least in the Cygnus version ofgettext).

My Makefile has @ characters in it.

This may mean that you tried to use an autoconf substitution in yourMakefile.in without adding the appropriate AC_SUBST callto your configure script. Or it may just mean that you need torebuild Makefile in your build directory. To rebuildMakefile from Makefile.in, run the shell scriptconfig.status with no arguments. If you need to forceconfigure 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 helpthem along.

Why do I have to run both config.status --recheck and config.status?

Normally, you don't; they will be run automatically by Makefiletargets. If you do need to run them, use config.status --recheckto run the configure script again with the same arguments as thefirst time you ran it. Use config.status (with no arguments) toregenerate all files (Makefile, config.h, etc.) based onthe results of the configure script. The two cases are separate becauseit isn't always necessary to regenerate all the files after runningconfig.status --recheck. The Makefile targets generatedby automake will use the environment variables CONFIG_FILES andCONFIG_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 GNUbinutils, and egcs. It is also, of course, used for Cygnus releases. It is the build system which was developed at Cygnus, using the Cygnusconfigure script. It permits building many different packages with asingle configure and make. The configure scripts in the tree are beingconverted 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 toolsthemselves which need to be fixed, and each time that happens everybodywho uses the tools need to reinstall new versions of them. I don't knowif 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 itseems unwise to assume that every configuration uses an appropriateprefix. It might be possible to make them work in place, or it might bepossible to install them in some subdirectory; so far these approacheshave not been implemented.

Index

• --build option: Build and Host Options
• --host option: Build and Host Options
• --target option: Specifying the Target
• _GNU_SOURCE : Write configure.in
• AC_CANONICAL_HOST : Using the Host Type
• AC_CANONICAL_SYSTEM : Using the Target Type
• AC_CONFIG_HEADER : Write configure.in
• AC_EXEEXT : Write configure.in
• AC_INIT : Write configure.in
• AC_OUTPUT : Write configure.in
• AC_PREREQ : Write configure.in
• AC_PROG_CC : Write configure.in
• AC_PROG_CXX : Write configure.in
• acconfig.h : Written Developer Files
• acconfig.h, writing: Write acconfig.h
• acinclude.m4 : Written Developer Files
• aclocal.m4 : Generated Developer Files
• AM_CONFIG_HEADER : Write configure.in
• AM_DISABLE_SHARED : Write configure.in
• AM_EXEEXT : Write configure.in
• AM_INIT_AUTOMAKE : Write configure.in
• AM_MAINTAINER_MODE : Write configure.in
• AM_PROG_LIBTOOL : Write configure.in
• AM_PROG_LIBTOOL in configure : FAQ
• build option: Build and Host Options
• building with a cross compiler: Canadian Cross
• canadian cross: Canadian Cross
• canadian cross in configure: CCross in Configure
• canadian cross in cygnus tree: CCross in Cygnus Tree
• canadian cross in makefile: CCross in Make
• canadian cross, configuring: Build and Host Options
• canonical system names: Configuration Names
• config.cache : Build Files Description
• config.h : Build Files Description
• config.h.in : Generated Developer Files
• config.in : Generated Developer Files
• config.status : Build Files Description
• config.status --recheck : FAQ
• configuration names: Configuration Names
• configuration triplets: Configuration Names
• configure : Generated Developer Files
• configure build system: Build and Host Options
• configure host: Build and Host Options
• configure target: Specifying the Target
• configure.in : Written Developer Files
• configure.in, writing: Write configure.in
• configuring a canadian cross: Build and Host Options
• cross compiler: Cross Compilation Concepts
• cross compiler, building with: Canadian Cross
• cross tools: Cross Compilation Tools
• CY_GNU_GETTEXT in configure : FAQ
• cygnus configure: Cygnus Configure
• goals: Goals
• history: History
• host names: Configuration Names
• host option: Build and Host Options
• host system: Host and Target
• host triplets: Configuration Names
• HOST_CC : CCross in Make
• libg++ configure: Cygnus Configure in C++ Libraries
• libio configure: Cygnus Configure in C++ Libraries
• libstdc++ configure: Cygnus Configure in C++ Libraries
• Makefile : Build Files Description
• Makefile, garbage characters: FAQ
• Makefile.am : Written Developer Files
• Makefile.am, writing: Write Makefile.am
• Makefile.in : Generated Developer Files
• multilibs: Multilibs
• stamp-h : Build Files Description
• stamp-h.in : Generated Developer Files
• system names: Configuration Names
• system types: Configuration Names
• target option: Specifying the Target
• target system: Host and Target
• triplets: Configuration Names
• undefined macros: FAQ

Reference Home

Corrections, suggestions, and new documentation should be posted to the Forum.

The text of the Arduino reference is licensed under a Creative Commons Attribution-ShareAlike 3.0 License. Code samples in the reference are released into the public domain.