1This is configure.info, produced by makeinfo version 4.7 from 2.././etc/configure.texi. 3 4INFO-DIR-SECTION GNU admin 5START-INFO-DIR-ENTRY 6* configure: (configure). The GNU configure and build system 7END-INFO-DIR-ENTRY 8 9 This file documents the GNU configure and build system. 10 11 Copyright (C) 1998 Cygnus Solutions. 12 13 Permission is granted to make and distribute verbatim copies of this 14manual provided the copyright notice and this permission notice are 15preserved on all copies. 16 17 Permission is granted to copy and distribute modified versions of 18this manual under the conditions for verbatim copying, provided that 19the entire resulting derived work is distributed under the terms of a 20permission notice identical to this one. 21 22 Permission is granted to copy and distribute translations of this 23manual into another language, under the above conditions for modified 24versions, except that this permission notice may be stated in a 25translation approved by the Foundation. 26 27 28File: configure.info, Node: Top, Next: Introduction, Up: (dir) 29 30GNU configure and build system 31****************************** 32 33The GNU configure and build system. 34 35* Menu: 36 37* Introduction:: Introduction. 38* Getting Started:: Getting Started. 39* Files:: Files. 40* Configuration Names:: Configuration Names. 41* Cross Compilation Tools:: Cross Compilation Tools. 42* Canadian Cross:: Canadian Cross. 43* Cygnus Configure:: Cygnus Configure. 44* Multilibs:: Multilibs. 45* FAQ:: Frequently Asked Questions. 46* Index:: Index. 47 48 49File: configure.info, Node: Introduction, Next: Getting Started, Prev: Top, Up: Top 50 511 Introduction 52************** 53 54This document describes the GNU configure and build systems. It 55describes how autoconf, automake, libtool, and make fit together. It 56also includes a discussion of the older Cygnus configure system. 57 58 This document does not describe in detail how to use each of the 59tools; see the respective manuals for that. Instead, it describes 60which files the developer must write, which files are machine generated 61and how they are generated, and where certain common problems should be 62addressed. 63 64 This document draws on several sources, including the autoconf 65manual by David MacKenzie (*note autoconf overview: (autoconf)Top.), 66the automake manual by David MacKenzie and Tom Tromey (*note automake 67overview: (automake)Top.), the libtool manual by Gordon Matzigkeit 68(*note libtool overview: (libtool)Top.), and the Cygnus configure 69manual by K. Richard Pixley. 70 71* Menu: 72 73* Goals:: Goals. 74* Tools:: The tools. 75* History:: History. 76* Building:: Building. 77 78 79File: configure.info, Node: Goals, Next: Tools, Up: Introduction 80 811.1 Goals 82========= 83 84The GNU configure and build system has two main goals. 85 86 The first is to simplify the development of portable programs. The 87system permits the developer to concentrate on writing the program, 88simplifying many details of portability across Unix and even Windows 89systems, and permitting the developer to describe how to build the 90program using simple rules rather than complex Makefiles. 91 92 The second is to simplify the building of programs distributed as 93source code. All programs are built using a simple, standardized, two 94step process. The program builder need not install any special tools in 95order to build the program. 96 97 98File: configure.info, Node: Tools, Next: History, Prev: Goals, Up: Introduction 99 1001.2 Tools 101========= 102 103The GNU configure and build system is comprised of several different 104tools. Program developers must build and install all of these tools. 105 106 People who just want to build programs from distributed sources 107normally do not need any special tools beyond a Unix shell, a make 108program, and a C compiler. 109 110autoconf 111 provides a general portability framework, based on testing the 112 features of the host system at build time. 113 114automake 115 a system for describing how to build a program, permitting the 116 developer to write a simplified `Makefile'. 117 118libtool 119 a standardized approach to building shared libraries. 120 121gettext 122 provides a framework for translation of text messages into other 123 languages; not really discussed in this document. 124 125m4 126 autoconf requires the GNU version of m4; the standard Unix m4 does 127 not suffice. 128 129perl 130 automake requires perl. 131 132 133File: configure.info, Node: History, Next: Building, Prev: Tools, Up: Introduction 134 1351.3 History 136=========== 137 138This is a very brief and probably inaccurate history. 139 140 As the number of Unix variants increased during the 1980s, it became 141harder to write programs which could run on all variants. While it was 142often possible to use `#ifdef' to identify particular systems, 143developers frequently did not have access to every system, and the 144characteristics of some systems changed from version to version. 145 146 By 1992, at least three different approaches had been developed: 147 * The Metaconfig program, by Larry Wall, Harlan Stenn, and Raphael 148 Manfredi. 149 150 * The Cygnus configure script, by K. Richard Pixley, and the gcc 151 configure script, by Richard Stallman. These use essentially the 152 same approach, and the developers communicated regularly. 153 154 * The autoconf program, by David MacKenzie. 155 156 The Metaconfig program is still used for Perl and a few other 157programs. It is part of the Dist package. I do not know if it is 158being developed. 159 160 In 1994, David MacKenzie and others modified autoconf to incorporate 161all the features of Cygnus configure. Since then, there has been a 162slow but steady conversion of GNU programs from Cygnus configure to 163autoconf. gcc has been converted, eliminating the gcc configure script. 164 165 GNU autoconf was regularly maintained until late 1996. As of this 166writing in June, 1998, it has no public maintainer. 167 168 Most programs are built using the make program, which requires the 169developer to write Makefiles describing how to build the programs. 170Since most programs are built in pretty much the same way, this led to a 171lot of duplication. 172 173 The X Window system is built using the imake tool, which uses a 174database of rules to eliminate the duplication. However, building a 175tool which was developed using imake requires that the builder have 176imake installed, violating one of the goals of the GNU system. 177 178 The new BSD make provides a standard library of Makefile fragments, 179which permits developers to write very simple Makefiles. However, this 180requires that the builder install the new BSD make program. 181 182 In 1994, David MacKenzie wrote the first version of automake, which 183permitted writing a simple build description which was converted into a 184Makefile which could be used by the standard make program. In 1995, Tom 185Tromey completely rewrote automake in Perl, and he continues to enhance 186it. 187 188 Various free packages built libraries, and by around 1995 several 189included support to build shared libraries on various platforms. 190However, there was no consistent approach. In early 1996, Gordon 191Matzigkeit began working on libtool, which provided a standardized 192approach to building shared libraries. This was integrated into 193automake from the start. 194 195 The development of automake and libtool was driven by the GNITS 196project, a group of GNU maintainers who designed standardized tools to 197help meet the GNU coding standards. 198 199 200File: configure.info, Node: Building, Prev: History, Up: Introduction 201 2021.4 Building 203============ 204 205Most readers of this document should already know how to build a tool by 206running `configure' and `make'. This section may serve as a quick 207introduction or reminder. 208 209 Building a tool is normally as simple as running `configure' 210followed by `make'. You should normally run `configure' from an empty 211directory, using some path to refer to the `configure' script in the 212source directory. The directory in which you run `configure' is called 213the "object directory". 214 215 In order to use a object directory which is different from the source 216directory, you must be using the GNU version of `make', which has the 217required `VPATH' support. Despite this restriction, using a different 218object directory is highly recommended: 219 * It keeps the files generated during the build from cluttering up 220 your sources. 221 222 * It permits you to remove the built files by simply removing the 223 entire build directory. 224 225 * It permits you to build from the same sources with several sets of 226 configure options simultaneously. 227 228 If you don't have GNU `make', you will have to run `configure' in 229the source directory. All GNU packages should support this; in 230particular, GNU packages should not assume the presence of GNU `make'. 231 232 After running `configure', you can build the tools by running `make'. 233 234 To install the tools, run `make install'. Installing the tools will 235copy the programs and any required support files to the "installation 236directory". The location of the installation directory is controlled 237by `configure' options, as described below. 238 239 In the Cygnus tree at present, the info files are built and 240installed as a separate step. To build them, run `make info'. To 241install them, run `make install-info'. 242 243 All `configure' scripts support a wide variety of options. The most 244interesting ones are `--with' and `--enable' options which are 245generally specific to particular tools. You can usually use the 246`--help' option to get a list of interesting options for a particular 247configure script. 248 249 The only generic options you are likely to use are the `--prefix' 250and `--exec-prefix' options. These options are used to specify the 251installation directory. 252 253 The directory named by the `--prefix' option will hold machine 254independent files such as info files. 255 256 The directory named by the `--exec-prefix' option, which is normally 257a subdirectory of the `--prefix' directory, will hold machine dependent 258files such as executables. 259 260 The default for `--prefix' is `/usr/local'. The default for 261`--exec-prefix' is the value used for `--prefix'. 262 263 The convention used in Cygnus releases is to use a `--prefix' option 264of `/usr/cygnus/RELEASE', where RELEASE is the name of the release, and 265to use a `--exec-prefix' option of `/usr/cygnus/RELEASE/H-HOST', where 266HOST is the configuration name of the host system (*note Configuration 267Names::). 268 269 Do not use either the source or the object directory as the 270installation directory. That will just lead to confusion. 271 272 273File: configure.info, Node: Getting Started, Next: Files, Prev: Introduction, Up: Top 274 2752 Getting Started 276***************** 277 278To start using the GNU configure and build system with your software 279package, you must write three files, and you must run some tools to 280manually generate additional files. 281 282* Menu: 283 284* Write configure.in:: Write configure.in. 285* Write Makefile.am:: Write Makefile.am. 286* Write acconfig.h:: Write acconfig.h. 287* Generate files:: Generate files. 288* Getting Started Example:: Example. 289 290 291File: configure.info, Node: Write configure.in, Next: Write Makefile.am, Up: Getting Started 292 2932.1 Write configure.in 294====================== 295 296You must first write the file `configure.in'. This is an autoconf 297input file, and the autoconf manual describes in detail what this file 298should look like. 299 300 You will write tests in your `configure.in' file to check for 301conditions that may change from one system to another, such as the 302presence of particular header files or functions. 303 304 For example, not all systems support the `gettimeofday' function. 305If you want to use the `gettimeofday' function when it is available, 306and to use some other function when it is not, you would check for this 307by putting `AC_CHECK_FUNCS(gettimeofday)' in `configure.in'. 308 309 When the configure script is run at build time, this will arrange to 310define the preprocessor macro `HAVE_GETTIMEOFDAY' to the value 1 if the 311`gettimeofday' function is available, and to not define the macro at 312all if the function is not available. Your code can then use `#ifdef' 313to test whether it is safe to call `gettimeofday'. 314 315 If you have an existing body of code, the `autoscan' program may 316help identify potential portability problems, and hence configure tests 317that you will want to use. *Note Invoking autoscan: (autoconf)Invoking 318autoscan. 319 320 Another handy tool for an existing body of code is `ifnames'. This 321will show you all the preprocessor conditionals that the code already 322uses. *Note Invoking ifnames: (autoconf)Invoking ifnames. 323 324 Besides the portability tests which are specific to your particular 325package, every `configure.in' file should contain the following macros. 326 327`AC_INIT' 328 This macro takes a single argument, which is the name of a file in 329 your package. For example, `AC_INIT(foo.c)'. 330 331`AC_PREREQ(VERSION)' 332 This macro is optional. It may be used to indicate the version of 333 `autoconf' that you are using. This will prevent users from 334 running an earlier version of `autoconf' and perhaps getting an 335 invalid `configure' script. For example, `AC_PREREQ(2.12)'. 336 337`AM_INIT_AUTOMAKE' 338 This macro takes two arguments: the name of the package, and a 339 version number. For example, `AM_INIT_AUTOMAKE(foo, 1.0)'. (This 340 macro is not needed if you are not using automake). 341 342`AM_CONFIG_HEADER' 343 This macro names the header file which will hold the preprocessor 344 macro definitions at run time. Normally this should be 345 `config.h'. Your sources would then use `#include "config.h"' to 346 include it. 347 348 This macro may optionally name the input file for that header 349 file; by default, this is `config.h.in', but that file name works 350 poorly on DOS filesystems. Therefore, it is often better to name 351 it explicitly as `config.in'. 352 353 This is what you should normally put in `configure.in': 354 AM_CONFIG_HEADER(config.h:config.in) 355 356 (If you are not using automake, use `AC_CONFIG_HEADER' rather than 357 `AM_CONFIG_HEADER'). 358 359`AM_MAINTAINER_MODE' 360 This macro always appears in Cygnus configure scripts. Other 361 programs may or may not use it. 362 363 If this macro is used, the `--enable-maintainer-mode' option is 364 required to enable automatic rebuilding of generated files used by 365 the configure system. This of course requires that developers be 366 aware of, and use, that option. 367 368 If this macro is not used, then the generated files will always be 369 rebuilt automatically. This will cause problems if the wrong 370 versions of autoconf, automake, or others are in the builder's 371 `PATH'. 372 373 (If you are not using automake, you do not need to use this macro). 374 375`AC_EXEEXT' 376 Either this macro or `AM_EXEEXT' always appears in Cygnus configure 377 files. Other programs may or may not use one of them. 378 379 This macro looks for the executable suffix used on the host 380 system. On Unix systems, this is the empty string. On Windows 381 systems, this is `.exe'. This macro directs automake to use the 382 executable suffix as appropriate when creating programs. This 383 macro does not take any arguments. 384 385 The `AC_EXEEXT' form is new, and is part of a Cygnus patch to 386 autoconf to support compiling with Visual C++. Older programs use 387 `AM_EXEEXT' instead. 388 389 (Programs which do not use automake use neither `AC_EXEEXT' nor 390 `AM_EXEEXT'). 391 392`AC_PROG_CC' 393 If you are writing C code, you will normally want to use this 394 macro. It locates the C compiler to use. It does not take any 395 arguments. 396 397 However, if this `configure.in' file is for a library which is to 398 be compiled by a cross compiler which may not fully work, then you 399 will not want to use `AC_PROG_CC'. Instead, you will want to use a 400 variant which does not call the macro `AC_PROG_CC_WORKS'. Examples 401 can be found in various `configure.in' files for libraries that are 402 compiled with cross compilers, such as libiberty or libgloss. 403 This is essentially a bug in autoconf, and there will probably be 404 a better workaround at some point. 405 406`AC_PROG_CXX' 407 If you are writing C++ code, you will want to use this macro. It 408 locates the C++ compiler to use. It does not take any arguments. 409 The same cross compiler comments apply as for `AC_PROG_CC'. 410 411`AM_PROG_LIBTOOL' 412 If you want to build libraries, and you want to permit them to be 413 shared, or you want to link against libraries which were built 414 using libtool, then you will need this macro. This macro is 415 required in order to use libtool. 416 417 By default, this will cause all libraries to be built as shared 418 libraries. To prevent this-to change the default-use 419 `AM_DISABLE_SHARED' before `AM_PROG_LIBTOOL'. The configure 420 options `--enable-shared' and `--disable-shared' may be used to 421 override the default at build time. 422 423`AC_DEFINE(_GNU_SOURCE)' 424 GNU packages should normally include this line before any other 425 feature tests. This defines the macro `_GNU_SOURCE' when 426 compiling, which directs the libc header files to provide the 427 standard GNU system interfaces including all GNU extensions. If 428 this macro is not defined, certain GNU extensions may not be 429 available. 430 431`AC_OUTPUT' 432 This macro takes a list of file names which the configure process 433 should produce. This is normally a list of one or more `Makefile' 434 files in different directories. If your package lives entirely in 435 a single directory, you would use simply `AC_OUTPUT(Makefile)'. 436 If you also have, for example, a `lib' subdirectory, you would use 437 `AC_OUTPUT(Makefile lib/Makefile)'. 438 439 If you want to use locally defined macros in your `configure.in' 440file, then you will need to write a `acinclude.m4' file which defines 441them (if not using automake, this file is called `aclocal.m4'). 442Alternatively, you can put separate macros in an `m4' subdirectory, and 443put `ACLOCAL_AMFLAGS = -I m4' in your `Makefile.am' file so that the 444`aclocal' program will be able to find them. 445 446 The different macro prefixes indicate which tool defines the macro. 447Macros which start with `AC_' are part of autoconf. Macros which start 448with `AM_' are provided by automake or libtool. 449 450 451File: configure.info, Node: Write Makefile.am, Next: Write acconfig.h, Prev: Write configure.in, Up: Getting Started 452 4532.2 Write Makefile.am 454===================== 455 456You must write the file `Makefile.am'. This is an automake input file, 457and the automake manual describes in detail what this file should look 458like. 459 460 The automake commands in `Makefile.am' mostly look like variable 461assignments in a `Makefile'. automake recognizes special variable 462names, and automatically add make rules to the output as needed. 463 464 There will be one `Makefile.am' file for each directory in your 465package. For each directory with subdirectories, the `Makefile.am' 466file should contain the line 467 SUBDIRS = DIR DIR ... 468 where each DIR is the name of a subdirectory. 469 470 For each `Makefile.am', there should be a corresponding `Makefile' 471in the `AC_OUTPUT' macro in `configure.in'. 472 473 Every `Makefile.am' written at Cygnus should contain the line 474 AUTOMAKE_OPTIONS = cygnus 475 This puts automake into Cygnus mode. See the automake manual for 476details. 477 478 You may to include the version number of `automake' that you are 479using on the `AUTOMAKE_OPTIONS' line. For example, 480 AUTOMAKE_OPTIONS = cygnus 1.3 481 This will prevent users from running an earlier version of 482`automake' and perhaps getting an invalid `Makefile.in'. 483 484 If your package builds a program, then in the directory where that 485program is built you will normally want a line like 486 bin_PROGRAMS = PROGRAM 487 where PROGRAM is the name of the program. You will then want a line 488like 489 PROGRAM_SOURCES = FILE FILE ... 490 where each FILE is the name of a source file to link into the 491program (e.g., `foo.c'). 492 493 If your package builds a library, and you do not want the library to 494ever be built as a shared library, then in the directory where that 495library is built you will normally want a line like 496 lib_LIBRARIES = libNAME.a 497 where `libNAME.a' is the name of the library. You will then want a 498line like 499 libNAME_a_SOURCES = FILE FILE ... 500 where each FILE is the name of a source file to add to the library. 501 502 If your package builds a library, and you want to permit building the 503library as a shared library, then in the directory where that library is 504built you will normally want a line like 505 lib_LTLIBRARIES = libNAME.la 506 The use of `LTLIBRARIES', and the `.la' extension, indicate a 507library to be built using libtool. As usual, you will then want a line 508like 509 libNAME_la_SOURCES = FILE FILE ... 510 511 The strings `bin' and `lib' that appear above in `bin_PROGRAMS' and 512`lib_LIBRARIES' are not arbitrary. They refer to particular 513directories, which may be set by the `--bindir' and `--libdir' options 514to `configure'. If those options are not used, the default values are 515based on the `--prefix' or `--exec-prefix' options to `configure'. It 516is possible to use other names if the program or library should be 517installed in some other directory. 518 519 The `Makefile.am' file may also contain almost anything that may 520appear in a normal `Makefile'. automake also supports many other 521special variables, as well as conditionals. 522 523 See the automake manual for more information. 524 525 526File: configure.info, Node: Write acconfig.h, Next: Generate files, Prev: Write Makefile.am, Up: Getting Started 527 5282.3 Write acconfig.h 529==================== 530 531If you are generating a portability header file, (i.e., you are using 532`AM_CONFIG_HEADER' in `configure.in'), then you will have to write a 533`acconfig.h' file. It will have to contain the following lines. 534 535 /* Name of package. */ 536 #undef PACKAGE 537 538 /* Version of package. */ 539 #undef VERSION 540 541 This requirement is really a bug in the system, and the requirement 542may be eliminated at some later date. 543 544 The `acconfig.h' file will also similar comment and `#undef' lines 545for any unusual macros in the `configure.in' file, including any macro 546which appears in a `AC_DEFINE' macro. 547 548 In particular, if you are writing a GNU package and therefore include 549`AC_DEFINE(_GNU_SOURCE)' in `configure.in' as suggested above, you will 550need lines like this in `acconfig.h': 551 /* Enable GNU extensions. */ 552 #undef _GNU_SOURCE 553 554 Normally the `autoheader' program will inform you of any such 555requirements by printing an error message when it is run. However, if 556you do anything particular odd in your `configure.in' file, you will 557have to make sure that the right entries appear in `acconfig.h', since 558otherwise the results of the tests may not be available in the 559`config.h' file which your code will use. 560 561 (Thee `PACKAGE' and `VERSION' lines are not required if you are not 562using automake, and in that case you may not need a `acconfig.h' file 563at all). 564 565 566File: configure.info, Node: Generate files, Next: Getting Started Example, Prev: Write acconfig.h, Up: Getting Started 567 5682.4 Generate files 569================== 570 571Once you have written `configure.in', `Makefile.am', `acconfig.h', and 572possibly `acinclude.m4', you must use autoconf and automake programs to 573produce the first versions of the generated files. This is done by 574executing the following sequence of commands. 575 576 aclocal 577 autoconf 578 autoheader 579 automake 580 581 The `aclocal' and `automake' commands are part of the automake 582package, and the `autoconf' and `autoheader' commands are part of the 583autoconf package. 584 585 If you are using a `m4' subdirectory for your macros, you will need 586to use the `-I m4' option when you run `aclocal'. 587 588 If you are not using the Cygnus tree, use the `-a' option when 589running `automake' command in order to copy the required support files 590into your source directory. 591 592 If you are using libtool, you must build and install the libtool 593package with the same `--prefix' and `--exec-prefix' options as you 594used with the autoconf and automake packages. You must do this before 595running any of the above commands. If you are not using the Cygnus 596tree, you will need to run the `libtoolize' program to copy the libtool 597support files into your directory. 598 599 Once you have managed to run these commands without getting any 600errors, you should create a new empty directory, and run the `configure' 601script which will have been created by `autoconf' with the 602`--enable-maintainer-mode' option. This will give you a set of 603Makefiles which will include rules to automatically rebuild all the 604generated files. 605 606 After doing that, whenever you have changed some of the input files 607and want to regenerated the other files, go to your object directory 608and run `make'. Doing this is more reliable than trying to rebuild the 609files manually, because there are complex order dependencies and it is 610easy to forget something. 611 612 613File: configure.info, Node: Getting Started Example, Prev: Generate files, Up: Getting Started 614 6152.5 Example 616=========== 617 618Let's consider a trivial example. 619 620 Suppose we want to write a simple version of `touch'. Our program, 621which we will call `poke', will take a single file name argument, and 622use the `utime' system call to set the modification and access times of 623the file to the current time. We want this program to be highly 624portable. 625 626 We'll first see what this looks like without using autoconf and 627automake, and then see what it looks like with them. 628 629* Menu: 630 631* Getting Started Example 1:: First Try. 632* Getting Started Example 2:: Second Try. 633* Getting Started Example 3:: Third Try. 634* Generate Files in Example:: Generate Files. 635 636 637File: configure.info, Node: Getting Started Example 1, Next: Getting Started Example 2, Up: Getting Started Example 638 6392.5.1 First Try 640--------------- 641 642Here is our first try at `poke.c'. Note that we've written it without 643ANSI/ISO C prototypes, since we want it to be highly portable. 644 645 #include <stdio.h> 646 #include <stdlib.h> 647 #include <sys/types.h> 648 #include <utime.h> 649 650 int 651 main (argc, argv) 652 int argc; 653 char **argv; 654 { 655 if (argc != 2) 656 { 657 fprintf (stderr, "Usage: poke file\n"); 658 exit (1); 659 } 660 661 if (utime (argv[1], NULL) < 0) 662 { 663 perror ("utime"); 664 exit (1); 665 } 666 667 exit (0); 668 } 669 670 We also write a simple `Makefile'. 671 672 CC = gcc 673 CFLAGS = -g -O2 674 675 all: poke 676 677 poke: poke.o 678 $(CC) -o poke $(CFLAGS) $(LDFLAGS) poke.o 679 680 So far, so good. 681 682 Unfortunately, there are a few problems. 683 684 On older Unix systems derived from BSD 4.3, the `utime' system call 685does not accept a second argument of `NULL'. On those systems, we need 686to pass a pointer to `struct utimbuf' structure. Unfortunately, even 687older systems don't define that structure; on those systems, we need to 688pass an array of two `long' values. 689 690 The header file `stdlib.h' was invented by ANSI C, and older systems 691don't have a copy. We included it above to get a declaration of `exit'. 692 693 We can find some of these portability problems by running 694`autoscan', which will create a `configure.scan' file which we can use 695as a prototype for our `configure.in' file. I won't show the output, 696but it will notice the potential problems with `utime' and `stdlib.h'. 697 698 In our `Makefile', we don't provide any way to install the program. 699This doesn't matter much for such a simple example, but a real program 700will need an `install' target. For that matter, we will also want a 701`clean' target. 702 703 704File: configure.info, Node: Getting Started Example 2, Next: Getting Started Example 3, Prev: Getting Started Example 1, Up: Getting Started Example 705 7062.5.2 Second Try 707---------------- 708 709Here is our second try at this program. 710 711 We modify `poke.c' to use preprocessor macros to control what 712features are available. (I've cheated a bit by using the same macro 713names which autoconf will use). 714 715 #include <stdio.h> 716 717 #ifdef STDC_HEADERS 718 #include <stdlib.h> 719 #endif 720 721 #include <sys/types.h> 722 723 #ifdef HAVE_UTIME_H 724 #include <utime.h> 725 #endif 726 727 #ifndef HAVE_UTIME_NULL 728 729 #include <time.h> 730 731 #ifndef HAVE_STRUCT_UTIMBUF 732 733 struct utimbuf 734 { 735 long actime; 736 long modtime; 737 }; 738 739 #endif 740 741 static int 742 utime_now (file) 743 char *file; 744 { 745 struct utimbuf now; 746 747 now.actime = now.modtime = time (NULL); 748 return utime (file, &now); 749 } 750 751 #define utime(f, p) utime_now (f) 752 753 #endif /* HAVE_UTIME_NULL */ 754 755 int 756 main (argc, argv) 757 int argc; 758 char **argv; 759 { 760 if (argc != 2) 761 { 762 fprintf (stderr, "Usage: poke file\n"); 763 exit (1); 764 } 765 766 if (utime (argv[1], NULL) < 0) 767 { 768 perror ("utime"); 769 exit (1); 770 } 771 772 exit (0); 773 } 774 775 Here is the associated `Makefile'. We've added support for the 776preprocessor flags we use. We've also added `install' and `clean' 777targets. 778 779 # Set this to your installation directory. 780 bindir = /usr/local/bin 781 782 # Uncomment this if you have the standard ANSI/ISO C header files. 783 # STDC_HDRS = -DSTDC_HEADERS 784 785 # Uncomment this if you have utime.h. 786 # UTIME_H = -DHAVE_UTIME_H 787 788 # Uncomment this if utime (FILE, NULL) works on your system. 789 # UTIME_NULL = -DHAVE_UTIME_NULL 790 791 # Uncomment this if struct utimbuf is defined in utime.h. 792 # UTIMBUF = -DHAVE_STRUCT_UTIMBUF 793 794 CC = gcc 795 CFLAGS = -g -O2 796 797 ALL_CFLAGS = $(STDC_HDRS) $(UTIME_H) $(UTIME_NULL) $(UTIMBUF) $(CFLAGS) 798 799 all: poke 800 801 poke: poke.o 802 $(CC) -o poke $(ALL_CFLAGS) $(LDFLAGS) poke.o 803 804 .c.o: 805 $(CC) -c $(ALL_CFLAGS) poke.c 806 807 install: poke 808 cp poke $(bindir)/poke 809 810 clean: 811 rm poke poke.o 812 813 Some problems with this approach should be clear. 814 815 Users who want to compile poke will have to know how `utime' works 816on their systems, so that they can uncomment the `Makefile' correctly. 817 818 The installation is done using `cp', but many systems have an 819`install' program which may be used, and which supports optional 820features such as stripping debugging information out of the installed 821binary. 822 823 The use of `Makefile' variables like `CC', `CFLAGS' and `LDFLAGS' 824follows the requirements of the GNU standards. This is convenient for 825all packages, since it reduces surprises for users. However, it is 826easy to get the details wrong, and wind up with a slightly nonstandard 827distribution. 828 829 830File: configure.info, Node: Getting Started Example 3, Next: Generate Files in Example, Prev: Getting Started Example 2, Up: Getting Started Example 831 8322.5.3 Third Try 833--------------- 834 835For our third try at this program, we will write a `configure.in' 836script to discover the configuration features on the host system, rather 837than requiring the user to edit the `Makefile'. We will also write a 838`Makefile.am' rather than a `Makefile'. 839 840 The only change to `poke.c' is to add a line at the start of the 841file: 842 #include "config.h" 843 844 The new `configure.in' file is as follows. 845 846 AC_INIT(poke.c) 847 AM_INIT_AUTOMAKE(poke, 1.0) 848 AM_CONFIG_HEADER(config.h:config.in) 849 AC_PROG_CC 850 AC_HEADER_STDC 851 AC_CHECK_HEADERS(utime.h) 852 AC_EGREP_HEADER(utimbuf, utime.h, AC_DEFINE(HAVE_STRUCT_UTIMBUF)) 853 AC_FUNC_UTIME_NULL 854 AC_OUTPUT(Makefile) 855 856 The first four macros in this file, and the last one, were described 857above; see *Note Write configure.in::. If we omit these macros, then 858when we run `automake' we will get a reminder that we need them. 859 860 The other macros are standard autoconf macros. 861 862`AC_HEADER_STDC' 863 Check for standard C headers. 864 865`AC_CHECK_HEADERS' 866 Check whether a particular header file exists. 867 868`AC_EGREP_HEADER' 869 Check for a particular string in a particular header file, in this 870 case checking for `utimbuf' in `utime.h'. 871 872`AC_FUNC_UTIME_NULL' 873 Check whether `utime' accepts a NULL second argument to set the 874 file change time to the current time. 875 876 See the autoconf manual for a more complete description. 877 878 The new `Makefile.am' file is as follows. Note how simple this is 879compared to our earlier `Makefile'. 880 881 bin_PROGRAMS = poke 882 883 poke_SOURCES = poke.c 884 885 This means that we should build a single program name `poke'. It 886should be installed in the binary directory, which we called `bindir' 887earlier. The program `poke' is built from the source file `poke.c'. 888 889 We must also write a `acconfig.h' file. Besides `PACKAGE' and 890`VERSION', which must be mentioned for all packages which use automake, 891we must include `HAVE_STRUCT_UTIMBUF', since we mentioned it in an 892`AC_DEFINE'. 893 894 /* Name of package. */ 895 #undef PACKAGE 896 897 /* Version of package. */ 898 #undef VERSION 899 900 /* Whether utime.h defines struct utimbuf. */ 901 #undef HAVE_STRUCT_UTIMBUF 902 903 904File: configure.info, Node: Generate Files in Example, Prev: Getting Started Example 3, Up: Getting Started Example 905 9062.5.4 Generate Files 907-------------------- 908 909We must now generate the other files, using the following commands. 910 911 aclocal 912 autoconf 913 autoheader 914 automake 915 916 When we run `autoheader', it will remind us of any macros we forgot 917to add to `acconfig.h'. 918 919 When we run `automake', it will want to add some files to our 920distribution. It will add them automatically if we use the 921`--add-missing' option. 922 923 By default, `automake' will run in GNU mode, which means that it 924will want us to create certain additional files; as of this writing, it 925will want `NEWS', `README', `AUTHORS', and `ChangeLog', all of which 926are files which should appear in a standard GNU distribution. We can 927either add those files, or run `automake' with the `--foreign' option. 928 929 Running these tools will generate the following files, all of which 930are described in the next chapter. 931 932 * `aclocal.m4' 933 934 * `configure' 935 936 * `config.in' 937 938 * `Makefile.in' 939 940 * `stamp-h.in' 941 942 943File: configure.info, Node: Files, Next: Configuration Names, Prev: Getting Started, Up: Top 944 9453 Files 946******* 947 948As was seen in the previous chapter, the GNU configure and build system 949uses a number of different files. The developer must write a few files. 950The others are generated by various tools. 951 952 The system is rather flexible, and can be used in many different 953ways. In describing the files that it uses, I will describe the common 954case, and mention some other cases that may arise. 955 956* Menu: 957 958* Developer Files:: Developer Files. 959* Build Files:: Build Files. 960* Support Files:: Support Files. 961 962 963File: configure.info, Node: Developer Files, Next: Build Files, Up: Files 964 9653.1 Developer Files 966=================== 967 968This section describes the files written or generated by the developer 969of a package. 970 971* Menu: 972 973* Developer Files Picture:: Developer Files Picture. 974* Written Developer Files:: Written Developer Files. 975* Generated Developer Files:: Generated Developer Files. 976 977 978File: configure.info, Node: Developer Files Picture, Next: Written Developer Files, Up: Developer Files 979 9803.1.1 Developer Files Picture 981----------------------------- 982 983Here is a picture of the files which are written by the developer, the 984generated files which would be included with a complete source 985distribution, and the tools which create those files. The file names 986are plain text and the tool names are enclosed by `*' characters (e.g., 987`autoheader' is the name of a tool, not the name of a file). 988 989 acconfig.h configure.in Makefile.am 990 | | | 991 | --------------+---------------------- | 992 | | | | | 993 v v | acinclude.m4 | | 994 *autoheader* | | v v 995 | | v --->*automake* 996 v |--->*aclocal* | | 997 config.in | | | v 998 | v | Makefile.in 999 | aclocal.m4--- 1000 | | 1001 v v 1002 *autoconf* 1003 | 1004 v 1005 configure 1006 1007 1008File: configure.info, Node: Written Developer Files, Next: Generated Developer Files, Prev: Developer Files Picture, Up: Developer Files 1009 10103.1.2 Written Developer Files 1011----------------------------- 1012 1013The following files would be written by the developer. 1014 1015`configure.in' 1016 This is the configuration script. This script contains 1017 invocations of autoconf macros. It may also contain ordinary 1018 shell script code. This file will contain feature tests for 1019 portability issues. The last thing in the file will normally be 1020 an `AC_OUTPUT' macro listing which files to create when the 1021 builder runs the configure script. This file is always required 1022 when using the GNU configure system. *Note Write configure.in::. 1023 1024`Makefile.am' 1025 This is the automake input file. It describes how the code should 1026 be built. It consists of definitions of automake variables. It 1027 may also contain ordinary Makefile targets. This file is only 1028 needed when using automake (newer tools normally use automake, but 1029 there are still older tools which have not been converted, in 1030 which the developer writes `Makefile.in' directly). *Note Write 1031 Makefile.am::. 1032 1033`acconfig.h' 1034 When the configure script creates a portability header file, by 1035 using `AM_CONFIG_HEADER' (or, if not using automake, 1036 `AC_CONFIG_HEADER'), this file is used to describe macros which are 1037 not recognized by the `autoheader' command. This is normally a 1038 fairly uninteresting file, consisting of a collection of `#undef' 1039 lines with comments. Normally any call to `AC_DEFINE' in 1040 `configure.in' will require a line in this file. *Note Write 1041 acconfig.h::. 1042 1043`acinclude.m4' 1044 This file is not always required. It defines local autoconf 1045 macros. These macros may then be used in `configure.in'. If you 1046 don't need any local autoconf macros, then you don't need this 1047 file at all. In fact, in general, you never need local autoconf 1048 macros, since you can put everything in `configure.in', but 1049 sometimes a local macro is convenient. 1050 1051 Newer tools may omit `acinclude.m4', and instead use a 1052 subdirectory, typically named `m4', and define `ACLOCAL_AMFLAGS = 1053 -I m4' in `Makefile.am' to force `aclocal' to look there for macro 1054 definitions. The macro definitions are then placed in separate 1055 files in that directory. 1056 1057 The `acinclude.m4' file is only used when using automake; in older 1058 tools, the developer writes `aclocal.m4' directly, if it is needed. 1059 1060 1061File: configure.info, Node: Generated Developer Files, Prev: Written Developer Files, Up: Developer Files 1062 10633.1.3 Generated Developer Files 1064------------------------------- 1065 1066The following files would be generated by the developer. 1067 1068 When using automake, these files are normally not generated manually 1069after the first time. Instead, the generated `Makefile' contains rules 1070to automatically rebuild the files as required. When 1071`AM_MAINTAINER_MODE' is used in `configure.in' (the normal case in 1072Cygnus code), the automatic rebuilding rules will only be defined if 1073you configure using the `--enable-maintainer-mode' option. 1074 1075 When using automatic rebuilding, it is important to ensure that all 1076the various tools have been built and installed on your `PATH'. Using 1077automatic rebuilding is highly recommended, so much so that I'm not 1078going to explain what you have to do if you don't use it. 1079 1080`configure' 1081 This is the configure script which will be run when building the 1082 package. This is generated by `autoconf' from `configure.in' and 1083 `aclocal.m4'. This is a shell script. 1084 1085`Makefile.in' 1086 This is the file which the configure script will turn into the 1087 `Makefile' at build time. This file is generated by `automake' 1088 from `Makefile.am'. If you aren't using automake, you must write 1089 this file yourself. This file is pretty much a normal `Makefile', 1090 with some configure substitutions for certain variables. 1091 1092`aclocal.m4' 1093 This file is created by the `aclocal' program, based on the 1094 contents of `configure.in' and `acinclude.m4' (or, as noted in the 1095 description of `acinclude.m4' above, on the contents of an `m4' 1096 subdirectory). This file contains definitions of autoconf macros 1097 which `autoconf' will use when generating the file `configure'. 1098 These autoconf macros may be defined by you in `acinclude.m4' or 1099 they may be defined by other packages such as automake, libtool or 1100 gettext. If you aren't using automake, you will normally write 1101 this file yourself; in that case, if `configure.in' uses only 1102 standard autoconf macros, this file will not be needed at all. 1103 1104`config.in' 1105 This file is created by `autoheader' based on `acconfig.h' and 1106 `configure.in'. At build time, the configure script will define 1107 some of the macros in it to create `config.h', which may then be 1108 included by your program. This permits your C code to use 1109 preprocessor conditionals to change its behaviour based on the 1110 characteristics of the host system. This file may also be called 1111 `config.h.in'. 1112 1113`stamp.h-in' 1114 This rather uninteresting file, which I omitted from the picture, 1115 is generated by `automake'. It always contains the string 1116 `timestamp'. It is used as a timestamp file indicating whether 1117 `config.in' is up to date. Using a timestamp file means that 1118 `config.in' can be marked as up to date without actually changing 1119 its modification time. This is useful since `config.in' depends 1120 upon `configure.in', but it is easy to change `configure.in' in a 1121 way which does not affect `config.in'. 1122 1123 1124File: configure.info, Node: Build Files, Next: Support Files, Prev: Developer Files, Up: Files 1125 11263.2 Build Files 1127=============== 1128 1129This section describes the files which are created at configure and 1130build time. These are the files which somebody who builds the package 1131will see. 1132 1133 Of course, the developer will also build the package. The 1134distinction between developer files and build files is not that the 1135developer does not see the build files, but that somebody who only 1136builds the package does not have to worry about the developer files. 1137 1138* Menu: 1139 1140* Build Files Picture:: Build Files Picture. 1141* Build Files Description:: Build Files Description. 1142 1143 1144File: configure.info, Node: Build Files Picture, Next: Build Files Description, Up: Build Files 1145 11463.2.1 Build Files Picture 1147------------------------- 1148 1149Here is a picture of the files which will be created at build time. 1150`config.status' is both a created file and a shell script which is run 1151to create other files, and the picture attempts to show that. 1152 1153 config.in *configure* Makefile.in 1154 | | | 1155 | v | 1156 | config.status | 1157 | | | 1158 *config.status*<======+==========>*config.status* 1159 | | 1160 v v 1161 config.h Makefile 1162 1163 1164File: configure.info, Node: Build Files Description, Prev: Build Files Picture, Up: Build Files 1165 11663.2.2 Build Files Description 1167----------------------------- 1168 1169This is a description of the files which are created at build time. 1170 1171`config.status' 1172 The first step in building a package is to run the `configure' 1173 script. The `configure' script will create the file 1174 `config.status', which is itself a shell script. When you first 1175 run `configure', it will automatically run `config.status'. An 1176 `Makefile' derived from an automake generated `Makefile.in' will 1177 contain rules to automatically run `config.status' again when 1178 necessary to recreate certain files if their inputs change. 1179 1180`Makefile' 1181 This is the file which make will read to build the program. The 1182 `config.status' script will transform `Makefile.in' into 1183 `Makefile'. 1184 1185`config.h' 1186 This file defines C preprocessor macros which C code can use to 1187 adjust its behaviour on different systems. The `config.status' 1188 script will transform `config.in' into `config.h'. 1189 1190`config.cache' 1191 This file did not fit neatly into the picture, and I omitted it. 1192 It is used by the `configure' script to cache results between 1193 runs. This can be an important speedup. If you modify 1194 `configure.in' in such a way that the results of old tests should 1195 change (perhaps you have added a new library to `LDFLAGS'), then 1196 you will have to remove `config.cache' to force the tests to be 1197 rerun. 1198 1199 The autoconf manual explains how to set up a site specific cache 1200 file. This can speed up running `configure' scripts on your 1201 system. 1202 1203`stamp.h' 1204 This file, which I omitted from the picture, is similar to 1205 `stamp-h.in'. It is used as a timestamp file indicating whether 1206 `config.h' is up to date. This is useful since `config.h' depends 1207 upon `config.status', but it is easy for `config.status' to change 1208 in a way which does not affect `config.h'. 1209 1210 1211File: configure.info, Node: Support Files, Prev: Build Files, Up: Files 1212 12133.3 Support Files 1214================= 1215 1216The GNU configure and build system requires several support files to be 1217included with your distribution. You do not normally need to concern 1218yourself with these. If you are using the Cygnus tree, most are already 1219present. Otherwise, they will be installed with your source by 1220`automake' (with the `--add-missing' option) and `libtoolize'. 1221 1222 You don't have to put the support files in the top level directory. 1223You can put them in a subdirectory, and use the `AC_CONFIG_AUX_DIR' 1224macro in `configure.in' to tell `automake' and the `configure' script 1225where they are. 1226 1227 In this section, I describe the support files, so that you can know 1228what they are and why they are there. 1229 1230`ABOUT-NLS' 1231 Added by automake if you are using gettext. This is a 1232 documentation file about the gettext project. 1233 1234`ansi2knr.c' 1235 Used by an automake generated `Makefile' if you put `ansi2knr' in 1236 `AUTOMAKE_OPTIONS' in `Makefile.am'. This permits compiling ANSI 1237 C code with a K&R C compiler. 1238 1239`ansi2knr.1' 1240 The man page which goes with `ansi2knr.c'. 1241 1242`config.guess' 1243 A shell script which determines the configuration name for the 1244 system on which it is run. 1245 1246`config.sub' 1247 A shell script which canonicalizes a configuration name entered by 1248 a user. 1249 1250`elisp-comp' 1251 Used to compile Emacs LISP files. 1252 1253`install-sh' 1254 A shell script which installs a program. This is used if the 1255 configure script can not find an install binary. 1256 1257`ltconfig' 1258 Used by libtool. This is a shell script which configures libtool 1259 for the particular system on which it is used. 1260 1261`ltmain.sh' 1262 Used by libtool. This is the actual libtool script which is used, 1263 after it is configured by `ltconfig' to build a library. 1264 1265`mdate-sh' 1266 A shell script used by an automake generated `Makefile' to pretty 1267 print the modification time of a file. This is used to maintain 1268 version numbers for texinfo files. 1269 1270`missing' 1271 A shell script used if some tool is missing entirely. This is 1272 used by an automake generated `Makefile' to avoid certain sorts of 1273 timestamp problems. 1274 1275`mkinstalldirs' 1276 A shell script which creates a directory, including all parent 1277 directories. This is used by an automake generated `Makefile' 1278 during installation. 1279 1280`texinfo.tex' 1281 Required if you have any texinfo files. This is used when 1282 converting Texinfo files into DVI using `texi2dvi' and TeX. 1283 1284`ylwrap' 1285 A shell script used by an automake generated `Makefile' to run 1286 programs like `bison', `yacc', `flex', and `lex'. These programs 1287 default to producing output files with a fixed name, and the 1288 `ylwrap' script runs them in a subdirectory to avoid file name 1289 conflicts when using a parallel make program. 1290 1291 1292File: configure.info, Node: Configuration Names, Next: Cross Compilation Tools, Prev: Files, Up: Top 1293 12944 Configuration Names 1295********************* 1296 1297The GNU configure system names all systems using a "configuration 1298name". All such names used to be triplets (they may now contain four 1299parts in certain cases), and the term "configuration triplet" is still 1300seen. 1301 1302* Menu: 1303 1304* Configuration Name Definition:: Configuration Name Definition. 1305* Using Configuration Names:: Using Configuration Names. 1306 1307 1308File: configure.info, Node: Configuration Name Definition, Next: Using Configuration Names, Up: Configuration Names 1309 13104.1 Configuration Name Definition 1311================================= 1312 1313This is a string of the form CPU-MANUFACTURER-OPERATING_SYSTEM. In 1314some cases, this is extended to a four part form: 1315CPU-MANUFACTURER-KERNEL-OPERATING_SYSTEM. 1316 1317 When using a configuration name in a configure option, it is normally 1318not necessary to specify an entire name. In particular, the 1319MANUFACTURER field is often omitted, leading to strings such as 1320`i386-linux' or `sparc-sunos'. The shell script `config.sub' will 1321translate these shortened strings into the canonical form. autoconf 1322will arrange for `config.sub' to be run automatically when it is needed. 1323 1324 The fields of a configuration name are as follows: 1325 1326CPU 1327 The type of processor. This is typically something like `i386' or 1328 `sparc'. More specific variants are used as well, such as 1329 `mipsel' to indicate a little endian MIPS processor. 1330 1331MANUFACTURER 1332 A somewhat freeform field which indicates the manufacturer of the 1333 system. This is often simply `unknown'. Other common strings are 1334 `pc' for an IBM PC compatible system, or the name of a workstation 1335 vendor, such as `sun'. 1336 1337OPERATING_SYSTEM 1338 The name of the operating system which is run on the system. This 1339 will be something like `solaris2.5' or `irix6.3'. There is no 1340 particular restriction on the version number, and strings like 1341 `aix4.1.4.0' are seen. For an embedded system, which has no 1342 operating system, this field normally indicates the type of object 1343 file format, such as `elf' or `coff'. 1344 1345KERNEL 1346 This is used mainly for GNU/Linux. A typical GNU/Linux 1347 configuration name is `i586-pc-linux-gnulibc1'. In this case the 1348 kernel, `linux', is separated from the operating system, 1349 `gnulibc1'. 1350 1351 The shell script `config.guess' will normally print the correct 1352configuration name for the system on which it is run. It does by 1353running `uname' and by examining other characteristics of the system. 1354 1355 Because `config.guess' can normally determine the configuration name 1356for a machine, it is normally only necessary to specify a configuration 1357name when building a cross-compiler or when building using a 1358cross-compiler. 1359 1360 1361File: configure.info, Node: Using Configuration Names, Prev: Configuration Name Definition, Up: Configuration Names 1362 13634.2 Using Configuration Names 1364============================= 1365 1366A configure script will sometimes have to make a decision based on a 1367configuration name. You will need to do this if you have to compile 1368code differently based on something which can not be tested using a 1369standard autoconf feature test. 1370 1371 It is normally better to test for particular features, rather than to 1372test for a particular system. This is because as Unix evolves, 1373different systems copy features from one another. Even if you need to 1374determine whether the feature is supported based on a configuration 1375name, you should define a macro which describes the feature, rather than 1376defining a macro which describes the particular system you are on. 1377 1378 Testing for a particular system is normally done using a case 1379statement in `configure.in'. The case statement might look something 1380like the following, assuming that `host' is a shell variable holding a 1381canonical configuration name (which will be the case if `configure.in' 1382uses the `AC_CANONICAL_HOST' or `AC_CANONICAL_SYSTEM' macro). 1383 1384 case "${host}" in 1385 i[3-7]86-*-linux-gnu*) do something ;; 1386 sparc*-sun-solaris2.[56789]*) do something ;; 1387 sparc*-sun-solaris*) do something ;; 1388 mips*-*-elf*) do something ;; 1389 esac 1390 1391 It is particularly important to use `*' after the operating system 1392field, in order to match the version number which will be generated by 1393`config.guess'. 1394 1395 In most cases you must be careful to match a range of processor 1396types. For most processor families, a trailing `*' suffices, as in 1397`mips*' above. For the i386 family, something along the lines of 1398`i[3-7]86' suffices at present. For the m68k family, you will need 1399something like `m68*'. Of course, if you do not need to match on the 1400processor, it is simpler to just replace the entire field by a `*', as 1401in `*-*-irix*'. 1402 1403 1404File: configure.info, Node: Cross Compilation Tools, Next: Canadian Cross, Prev: Configuration Names, Up: Top 1405 14065 Cross Compilation Tools 1407************************* 1408 1409The GNU configure and build system can be used to build "cross 1410compilation" tools. A cross compilation tool is a tool which runs on 1411one system and produces code which runs on another system. 1412 1413* Menu: 1414 1415* Cross Compilation Concepts:: Cross Compilation Concepts. 1416* Host and Target:: Host and Target. 1417* Using the Host Type:: Using the Host Type. 1418* Specifying the Target:: Specifying the Target. 1419* Using the Target Type:: Using the Target Type. 1420* Cross Tools in the Cygnus Tree:: Cross Tools in the Cygnus Tree 1421 1422 1423File: configure.info, Node: Cross Compilation Concepts, Next: Host and Target, Up: Cross Compilation Tools 1424 14255.1 Cross Compilation Concepts 1426============================== 1427 1428A compiler which produces programs which run on a different system is a 1429cross compilation compiler, or simply a "cross compiler". Similarly, 1430we speak of cross assemblers, cross linkers, etc. 1431 1432 In the normal case, a compiler produces code which runs on the same 1433system as the one on which the compiler runs. When it is necessary to 1434distinguish this case from the cross compilation case, such a compiler 1435is called a "native compiler". Similarly, we speak of native 1436assemblers, etc. 1437 1438 Although the debugger is not strictly speaking a compilation tool, 1439it is nevertheless meaningful to speak of a cross debugger: a debugger 1440which is used to debug code which runs on another system. Everything 1441that is said below about configuring cross compilation tools applies to 1442the debugger as well. 1443 1444 1445File: configure.info, Node: Host and Target, Next: Using the Host Type, Prev: Cross Compilation Concepts, Up: Cross Compilation Tools 1446 14475.2 Host and Target 1448=================== 1449 1450When building cross compilation tools, there are two different systems 1451involved: the system on which the tools will run, and the system for 1452which the tools generate code. 1453 1454 The system on which the tools will run is called the "host" system. 1455 1456 The system for which the tools generate code is called the "target" 1457system. 1458 1459 For example, suppose you have a compiler which runs on a GNU/Linux 1460system and generates ELF programs for a MIPS embedded system. In this 1461case the GNU/Linux system is the host, and the MIPS ELF system is the 1462target. Such a compiler could be called a GNU/Linux cross MIPS ELF 1463compiler, or, equivalently, a `i386-linux-gnu' cross `mips-elf' 1464compiler. 1465 1466 Naturally, most programs are not cross compilation tools. For those 1467programs, it does not make sense to speak of a target. It only makes 1468sense to speak of a target for tools like `gcc' or the `binutils' which 1469actually produce running code. For example, it does not make sense to 1470speak of the target of a tool like `bison' or `make'. 1471 1472 Most cross compilation tools can also serve as native tools. For a 1473native compilation tool, it is still meaningful to speak of a target. 1474For a native tool, the target is the same as the host. For example, for 1475a GNU/Linux native compiler, the host is GNU/Linux, and the target is 1476also GNU/Linux. 1477 1478 1479File: configure.info, Node: Using the Host Type, Next: Specifying the Target, Prev: Host and Target, Up: Cross Compilation Tools 1480 14815.3 Using the Host Type 1482======================= 1483 1484In almost all cases the host system is the system on which you run the 1485`configure' script, and on which you build the tools (for the case when 1486they differ, *note Canadian Cross::). 1487 1488 If your configure script needs to know the configuration name of the 1489host system, and the package is not a cross compilation tool and 1490therefore does not have a target, put `AC_CANONICAL_HOST' in 1491`configure.in'. This macro will arrange to define a few shell 1492variables when the `configure' script is run. 1493 1494`host' 1495 The canonical configuration name of the host. This will normally 1496 be determined by running the `config.guess' shell script, although 1497 the user is permitted to override this by using an explicit 1498 `--host' option. 1499 1500`host_alias' 1501 In the unusual case that the user used an explicit `--host' option, 1502 this will be the argument to `--host'. In the normal case, this 1503 will be the same as the `host' variable. 1504 1505`host_cpu' 1506`host_vendor' 1507`host_os' 1508 The first three parts of the canonical configuration name. 1509 1510 The shell variables may be used by putting shell code in 1511`configure.in'. For an example, see *Note Using Configuration Names::. 1512 1513 1514File: configure.info, Node: Specifying the Target, Next: Using the Target Type, Prev: Using the Host Type, Up: Cross Compilation Tools 1515 15165.4 Specifying the Target 1517========================= 1518 1519By default, the `configure' script will assume that the target is the 1520same as the host. This is the more common case; for example, it leads 1521to a native compiler rather than a cross compiler. 1522 1523 If you want to build a cross compilation tool, you must specify the 1524target explicitly by using the `--target' option when you run 1525`configure'. The argument to `--target' is the configuration name of 1526the system for which you wish to generate code. *Note Configuration 1527Names::. 1528 1529 For example, to build tools which generate code for a MIPS ELF 1530embedded system, you would use `--target mips-elf'. 1531 1532 1533File: configure.info, Node: Using the Target Type, Next: Cross Tools in the Cygnus Tree, Prev: Specifying the Target, Up: Cross Compilation Tools 1534 15355.5 Using the Target Type 1536========================= 1537 1538When writing `configure.in' for a cross compilation tool, you will need 1539to use information about the target. To do this, put 1540`AC_CANONICAL_SYSTEM' in `configure.in'. 1541 1542 `AC_CANONICAL_SYSTEM' will look for a `--target' option and 1543canonicalize it using the `config.sub' shell script. It will also run 1544`AC_CANONICAL_HOST' (*note Using the Host Type::). 1545 1546 The target type will be recorded in the following shell variables. 1547Note that the host versions of these variables will also be defined by 1548`AC_CANONICAL_HOST'. 1549 1550`target' 1551 The canonical configuration name of the target. 1552 1553`target_alias' 1554 The argument to the `--target' option. If the user did not specify 1555 a `--target' option, this will be the same as `host_alias'. 1556 1557`target_cpu' 1558`target_vendor' 1559`target_os' 1560 The first three parts of the canonical target configuration name. 1561 1562 Note that if `host' and `target' are the same string, you can assume 1563a native configuration. If they are different, you can assume a cross 1564configuration. 1565 1566 It is arguably possible for `host' and `target' to represent the 1567same system, but for the strings to not be identical. For example, if 1568`config.guess' returns `sparc-sun-sunos4.1.4', and somebody configures 1569with `--target sparc-sun-sunos4.1', then the slight differences between 1570the two versions of SunOS may be unimportant for your tool. However, 1571in the general case it can be quite difficult to determine whether the 1572differences between two configuration names are significant or not. 1573Therefore, by convention, if the user specifies a `--target' option 1574without specifying a `--host' option, it is assumed that the user wants 1575to configure a cross compilation tool. 1576 1577 The variables `target' and `target_alias' should be handled 1578differently. 1579 1580 In general, whenever the user may actually see a string, 1581`target_alias' should be used. This includes anything which may appear 1582in the file system, such as a directory name or part of a tool name. 1583It also includes any tool output, unless it is clearly labelled as the 1584canonical target configuration name. This permits the user to use the 1585`--target' option to specify how the tool will appear to the outside 1586world. 1587 1588 On the other hand, when checking for characteristics of the target 1589system, `target' should be used. This is because a wide variety of 1590`--target' options may map into the same canonical configuration name. 1591You should not attempt to duplicate the canonicalization done by 1592`config.sub' in your own code. 1593 1594 By convention, cross tools are installed with a prefix of the 1595argument used with the `--target' option, also known as `target_alias' 1596(*note Using the Target Type::). If the user does not use the 1597`--target' option, and thus is building a native tool, no prefix is 1598used. 1599 1600 For example, if gcc is configured with `--target mips-elf', then the 1601installed binary will be named `mips-elf-gcc'. If gcc is configured 1602without a `--target' option, then the installed binary will be named 1603`gcc'. 1604 1605 The autoconf macro `AC_ARG_PROGRAM' will handle this for you. If 1606you are using automake, no more need be done; the programs will 1607automatically be installed with the correct prefixes. Otherwise, see 1608the autoconf documentation for `AC_ARG_PROGRAM'. 1609 1610 1611File: configure.info, Node: Cross Tools in the Cygnus Tree, Prev: Using the Target Type, Up: Cross Compilation Tools 1612 16135.6 Cross Tools in the Cygnus Tree 1614================================== 1615 1616The Cygnus tree is used for various packages including gdb, the GNU 1617binutils, and egcs. It is also, of course, used for Cygnus releases. 1618 1619 In the Cygnus tree, the top level `configure' script uses the old 1620Cygnus configure system, not autoconf. The top level `Makefile.in' is 1621written to build packages based on what is in the source tree, and 1622supports building a large number of tools in a single 1623`configure'/`make' step. 1624 1625 The Cygnus tree may be configured with a `--target' option. The 1626`--target' option applies recursively to every subdirectory, and 1627permits building an entire set of cross tools at once. 1628 1629* Menu: 1630 1631* Host and Target Libraries:: Host and Target Libraries. 1632* Target Library Configure Scripts:: Target Library Configure Scripts. 1633* Make Targets in Cygnus Tree:: Make Targets in Cygnus Tree. 1634* Target libiberty:: Target libiberty 1635 1636 1637File: configure.info, Node: Host and Target Libraries, Next: Target Library Configure Scripts, Up: Cross Tools in the Cygnus Tree 1638 16395.6.1 Host and Target Libraries 1640------------------------------- 1641 1642The Cygnus tree distinguishes host libraries from target libraries. 1643 1644 Host libraries are built with the compiler used to build the programs 1645which run on the host, which is called the host compiler. This includes 1646libraries such as `bfd' and `tcl'. These libraries are built with the 1647host compiler, and are linked into programs like the binutils or gcc 1648which run on the host. 1649 1650 Target libraries are built with the target compiler. If gcc is 1651present in the source tree, then the target compiler is the gcc that is 1652built using the host compiler. Target libraries are libraries such as 1653`newlib' and `libstdc++'. These libraries are not linked into the host 1654programs, but are instead made available for use with programs built 1655with the target compiler. 1656 1657 For the rest of this section, assume that gcc is present in the 1658source tree, so that it will be used to build the target libraries. 1659 1660 There is a complication here. The configure process needs to know 1661which compiler you are going to use to build a tool; otherwise, the 1662feature tests will not work correctly. The Cygnus tree handles this by 1663not configuring the target libraries until the target compiler is 1664built. In order to permit everything to build using a single 1665`configure'/`make', the configuration of the target libraries is 1666actually triggered during the make step. 1667 1668 When the target libraries are configured, the `--target' option is 1669not used. Instead, the `--host' option is used with the argument of 1670the `--target' option for the overall configuration. If no `--target' 1671option was used for the overall configuration, the `--host' option will 1672be passed with the output of the `config.guess' shell script. Any 1673`--build' option is passed down unchanged. 1674 1675 This translation of configuration options is done because since the 1676target libraries are compiled with the target compiler, they are being 1677built in order to run on the target of the overall configuration. By 1678the definition of host, this means that their host system is the same as 1679the target system of the overall configuration. 1680 1681 The same process is used for both a native configuration and a cross 1682configuration. Even when using a native configuration, the target 1683libraries will be configured and built using the newly built compiler. 1684This is particularly important for the C++ libraries, since there is no 1685reason to assume that the C++ compiler used to build the host tools (if 1686there even is one) uses the same ABI as the g++ compiler which will be 1687used to build the target libraries. 1688 1689 There is one difference between a native configuration and a cross 1690configuration. In a native configuration, the target libraries are 1691normally configured and built as siblings of the host tools. In a cross 1692configuration, the target libraries are normally built in a subdirectory 1693whose name is the argument to `--target'. This is mainly for 1694historical reasons. 1695 1696 To summarize, running `configure' in the Cygnus tree configures all 1697the host libraries and tools, but does not configure any of the target 1698libraries. Running `make' then does the following steps: 1699 1700 * Build the host libraries. 1701 1702 * Build the host programs, including gcc. Note that we call gcc 1703 both a host program (since it runs on the host) and a target 1704 compiler (since it generates code for the target). 1705 1706 * Using the newly built target compiler, configure the target 1707 libraries. 1708 1709 * Build the target libraries. 1710 1711 The steps need not be done in precisely this order, since they are 1712actually controlled by `Makefile' targets. 1713 1714 1715File: configure.info, Node: Target Library Configure Scripts, Next: Make Targets in Cygnus Tree, Prev: Host and Target Libraries, Up: Cross Tools in the Cygnus Tree 1716 17175.6.2 Target Library Configure Scripts 1718-------------------------------------- 1719 1720There are a few things you must know in order to write a configure 1721script for a target library. This is just a quick sketch, and beginners 1722shouldn't worry if they don't follow everything here. 1723 1724 The target libraries are configured and built using a newly built 1725target compiler. There may not be any startup files or libraries for 1726this target compiler. In fact, those files will probably be built as 1727part of some target library, which naturally means that they will not 1728exist when your target library is configured. 1729 1730 This means that the configure script for a target library may not use 1731any test which requires doing a link. This unfortunately includes many 1732useful autoconf macros, such as `AC_CHECK_FUNCS'. autoconf macros 1733which do a compile but not a link, such as `AC_CHECK_HEADERS', may be 1734used. 1735 1736 This is a severe restriction, but normally not a fatal one, as target 1737libraries can often assume the presence of other target libraries, and 1738thus know which functions will be available. 1739 1740 As of this writing, the autoconf macro `AC_PROG_CC' does a link to 1741make sure that the compiler works. This may fail in a target library, 1742so target libraries must use a different set of macros to locate the 1743compiler. See the `configure.in' file in a directory like `libiberty' 1744or `libgloss' for an example. 1745 1746 As noted in the previous section, target libraries are sometimes 1747built in directories which are siblings to the host tools, and are 1748sometimes built in a subdirectory. The `--with-target-subdir' configure 1749option will be passed when the library is configured. Its value will be 1750an empty string if the target library is a sibling. Its value will be 1751the name of the subdirectory if the target library is in a subdirectory. 1752 1753 If the overall build is not a native build (i.e., the overall 1754configure used the `--target' option), then the library will be 1755configured with the `--with-cross-host' option. The value of this 1756option will be the host system of the overall build. Recall that the 1757host system of the library will be the target of the overall build. If 1758the overall build is a native build, the `--with-cross-host' option 1759will not be used. 1760 1761 A library which can be built both standalone and as a target library 1762may want to install itself into different directories depending upon the 1763case. When built standalone, or when built native, the library should 1764be installed in `$(libdir)'. When built as a target library which is 1765not native, the library should be installed in `$(tooldir)/lib'. The 1766`--with-cross-host' option may be used to distinguish these cases. 1767 1768 This same test of `--with-cross-host' may be used to see whether it 1769is OK to use link tests in the configure script. If the 1770`--with-cross-host' option is not used, then the library is being built 1771either standalone or native, and a link should work. 1772 1773 1774File: configure.info, Node: Make Targets in Cygnus Tree, Next: Target libiberty, Prev: Target Library Configure Scripts, Up: Cross Tools in the Cygnus Tree 1775 17765.6.3 Make Targets in Cygnus Tree 1777--------------------------------- 1778 1779The top level `Makefile' in the Cygnus tree defines targets for every 1780known subdirectory. 1781 1782 For every subdirectory DIR which holds a host library or program, 1783the `Makefile' target `all-DIR' will build that library or program. 1784 1785 There are dependencies among host tools. For example, building gcc 1786requires first building gas, because the gcc build process invokes the 1787target assembler. These dependencies are reflected in the top level 1788`Makefile'. 1789 1790 For every subdirectory DIR which holds a target library, the 1791`Makefile' target `configure-target-DIR' will configure that library. 1792The `Makefile' target `all-target-DIR' will build that library. 1793 1794 Every `configure-target-DIR' target depends upon `all-gcc', since 1795gcc, the target compiler, is required to configure the tool. Every 1796`all-target-DIR' target depends upon the corresponding 1797`configure-target-DIR' target. 1798 1799 There are several other targets which may be of interest for each 1800directory: `install-DIR', `clean-DIR', and `check-DIR'. There are also 1801corresponding `target' versions of these for the target libraries , 1802such as `install-target-DIR'. 1803 1804 1805File: configure.info, Node: Target libiberty, Prev: Make Targets in Cygnus Tree, Up: Cross Tools in the Cygnus Tree 1806 18075.6.4 Target libiberty 1808---------------------- 1809 1810The `libiberty' subdirectory is currently a special case, in that it is 1811the only directory which is built both using the host compiler and 1812using the target compiler. 1813 1814 This is because the files in `libiberty' are used when building the 1815host tools, and they are also incorporated into the `libstdc++' target 1816library as support code. 1817 1818 This duality does not pose any particular difficulties. It means 1819that there are targets for both `all-libiberty' and 1820`all-target-libiberty'. 1821 1822 In a native configuration, when target libraries are not built in a 1823subdirectory, the same objects are normally used as both the host build 1824and the target build. This is normally OK, since libiberty contains 1825only C code, and in a native configuration the results of the host 1826compiler and the target compiler are normally interoperable. 1827 1828 Irix 6 is again an exception here, since the SGI native compiler 1829defaults to using the `O32' ABI, and gcc defaults to using the `N32' 1830ABI. On Irix 6, the target libraries are built in a subdirectory even 1831for a native configuration, avoiding this problem. 1832 1833 There are currently no other libraries built for both the host and 1834the target, but there is no conceptual problem with adding more. 1835 1836 1837File: configure.info, Node: Canadian Cross, Next: Cygnus Configure, Prev: Cross Compilation Tools, Up: Top 1838 18396 Canadian Cross 1840**************** 1841 1842It is possible to use the GNU configure and build system to build a 1843program which will run on a system which is different from the system on 1844which the tools are built. In other words, it is possible to build 1845programs using a cross compiler. 1846 1847 This is referred to as a "Canadian Cross". 1848 1849* Menu: 1850 1851* Canadian Cross Example:: Canadian Cross Example. 1852* Canadian Cross Concepts:: Canadian Cross Concepts. 1853* Build Cross Host Tools:: Build Cross Host Tools. 1854* Build and Host Options:: Build and Host Options. 1855* CCross not in Cygnus Tree:: Canadian Cross not in Cygnus Tree. 1856* CCross in Cygnus Tree:: Canadian Cross in Cygnus Tree. 1857* Supporting Canadian Cross:: Supporting Canadian Cross. 1858 1859 1860File: configure.info, Node: Canadian Cross Example, Next: Canadian Cross Concepts, Up: Canadian Cross 1861 18626.1 Canadian Cross Example 1863========================== 1864 1865Here is an example of a Canadian Cross. 1866 1867 While running on a GNU/Linux, you can build a program which will run 1868on a Solaris system. You would use a GNU/Linux cross Solaris compiler 1869to build the program. 1870 1871 Of course, you could not run the resulting program on your GNU/Linux 1872system. You would have to copy it over to a Solaris system before you 1873would run it. 1874 1875 Of course, you could also simply build the programs on the Solaris 1876system in the first place. However, perhaps the Solaris system is not 1877available for some reason; perhaps you actually don't have one, but you 1878want to build the tools for somebody else to use. Or perhaps your 1879GNU/Linux system is much faster than your Solaris system. 1880 1881 A Canadian Cross build is most frequently used when building 1882programs to run on a non-Unix system, such as DOS or Windows. It may 1883be simpler to configure and build on a Unix system than to support the 1884configuration machinery on a non-Unix system. 1885 1886 1887File: configure.info, Node: Canadian Cross Concepts, Next: Build Cross Host Tools, Prev: Canadian Cross Example, Up: Canadian Cross 1888 18896.2 Canadian Cross Concepts 1890=========================== 1891 1892When building a Canadian Cross, there are at least two different systems 1893involved: the system on which the tools are being built, and the system 1894on which the tools will run. 1895 1896 The system on which the tools are being built is called the "build" 1897system. 1898 1899 The system on which the tools will run is called the host system. 1900 1901 For example, if you are building a Solaris program on a GNU/Linux 1902system, as in the previous section, the build system would be GNU/Linux, 1903and the host system would be Solaris. 1904 1905 It is, of course, possible to build a cross compiler using a Canadian 1906Cross (i.e., build a cross compiler using a cross compiler). In this 1907case, the system for which the resulting cross compiler generates code 1908is called the target system. (For a more complete discussion of host 1909and target systems, *note Host and Target::). 1910 1911 An example of building a cross compiler using a Canadian Cross would 1912be building a Windows cross MIPS ELF compiler on a GNU/Linux system. In 1913this case the build system would be GNU/Linux, the host system would be 1914Windows, and the target system would be MIPS ELF. 1915 1916 The name Canadian Cross comes from the case when the build, host, and 1917target systems are all different. At the time that these issues were 1918all being hashed out, Canada had three national political parties. 1919 1920 1921File: configure.info, Node: Build Cross Host Tools, Next: Build and Host Options, Prev: Canadian Cross Concepts, Up: Canadian Cross 1922 19236.3 Build Cross Host Tools 1924========================== 1925 1926In order to configure a program for a Canadian Cross build, you must 1927first build and install the set of cross tools you will use to build the 1928program. 1929 1930 These tools will be build cross host tools. That is, they will run 1931on the build system, and will produce code that runs on the host system. 1932 1933 It is easy to confuse the meaning of build and host here. Always 1934remember that the build system is where you are doing the build, and the 1935host system is where the resulting program will run. Therefore, you 1936need a build cross host compiler. 1937 1938 In general, you must have a complete cross environment in order to do 1939the build. This normally means a cross compiler, cross assembler, and 1940so forth, as well as libraries and include files for the host system. 1941 1942 1943File: configure.info, Node: Build and Host Options, Next: CCross not in Cygnus Tree, Prev: Build Cross Host Tools, Up: Canadian Cross 1944 19456.4 Build and Host Options 1946========================== 1947 1948When you run `configure', you must use both the `--build' and `--host' 1949options. 1950 1951 The `--build' option is used to specify the configuration name of 1952the build system. This can normally be the result of running the 1953`config.guess' shell script, and it is reasonable to use 1954`--build=`config.guess`'. 1955 1956 The `--host' option is used to specify the configuration name of the 1957host system. 1958 1959 As we explained earlier, `config.guess' is used to set the default 1960value for the `--host' option (*note Using the Host Type::). We can 1961now see that since `config.guess' returns the type of system on which 1962it is run, it really identifies the build system. Since the host 1963system is normally the same as the build system (i.e., people do not 1964normally build using a cross compiler), it is reasonable to use the 1965result of `config.guess' as the default for the host system when the 1966`--host' option is not used. 1967 1968 It might seem that if the `--host' option were used without the 1969`--build' option that the configure script could run `config.guess' to 1970determine the build system, and presume a Canadian Cross if the result 1971of `config.guess' differed from the `--host' option. However, for 1972historical reasons, some configure scripts are routinely run using an 1973explicit `--host' option, rather than using the default from 1974`config.guess'. As noted earlier, it is difficult or impossible to 1975reliably compare configuration names (*note Using the Target Type::). 1976Therefore, by convention, if the `--host' option is used, but the 1977`--build' option is not used, then the build system defaults to the 1978host system. 1979 1980 1981File: configure.info, Node: CCross not in Cygnus Tree, Next: CCross in Cygnus Tree, Prev: Build and Host Options, Up: Canadian Cross 1982 19836.5 Canadian Cross not in Cygnus Tree. 1984====================================== 1985 1986If you are not using the Cygnus tree, you must explicitly specify the 1987cross tools which you want to use to build the program. This is done by 1988setting environment variables before running the `configure' script. 1989 1990 You must normally set at least the environment variables `CC', `AR', 1991and `RANLIB' to the cross tools which you want to use to build. 1992 1993 For some programs, you must set additional cross tools as well, such 1994as `AS', `LD', or `NM'. 1995 1996 You would set these environment variables to the build cross tools 1997which you are going to use. 1998 1999 For example, if you are building a Solaris program on a GNU/Linux 2000system, and your GNU/Linux cross Solaris compiler were named 2001`solaris-gcc', then you would set the environment variable `CC' to 2002`solaris-gcc'. 2003 2004 2005File: configure.info, Node: CCross in Cygnus Tree, Next: Supporting Canadian Cross, Prev: CCross not in Cygnus Tree, Up: Canadian Cross 2006 20076.6 Canadian Cross in Cygnus Tree 2008================================= 2009 2010This section describes configuring and building a Canadian Cross when 2011using the Cygnus tree. 2012 2013* Menu: 2014 2015* Standard Cygnus CCross:: Building a Normal Program. 2016* Cross Cygnus CCross:: Building a Cross Program. 2017 2018 2019File: configure.info, Node: Standard Cygnus CCross, Next: Cross Cygnus CCross, Up: CCross in Cygnus Tree 2020 20216.6.1 Building a Normal Program 2022------------------------------- 2023 2024When configuring a Canadian Cross in the Cygnus tree, all the 2025appropriate environment variables are automatically set to `HOST-TOOL', 2026where HOST is the value used for the `--host' option, and TOOL is the 2027name of the tool (e.g., `gcc', `as', etc.). These tools must be on 2028your `PATH'. 2029 2030 Adding a prefix of HOST will give the usual name for the build cross 2031host tools. To see this, consider that when these cross tools were 2032built, they were configured to run on the build system and to produce 2033code for the host system. That is, they were configured with a 2034`--target' option that is the same as the system which we are now 2035calling the host. Recall that the default name for installed cross 2036tools uses the target system as a prefix (*note Using the Target 2037Type::). Since that is the system which we are now calling the host, 2038HOST is the right prefix to use. 2039 2040 For example, if you configure with `--build=i386-linux-gnu' and 2041`--host=solaris', then the Cygnus tree will automatically default to 2042using the compiler `solaris-gcc'. You must have previously built and 2043installed this compiler, probably by doing a build with no `--host' 2044option and with a `--target' option of `solaris'. 2045 2046 2047File: configure.info, Node: Cross Cygnus CCross, Prev: Standard Cygnus CCross, Up: CCross in Cygnus Tree 2048 20496.6.2 Building a Cross Program 2050------------------------------ 2051 2052There are additional considerations if you want to build a cross 2053compiler, rather than a native compiler, in the Cygnus tree using a 2054Canadian Cross. 2055 2056 When you build a cross compiler using the Cygnus tree, then the 2057target libraries will normally be built with the newly built target 2058compiler (*note Host and Target Libraries::). However, this will not 2059work when building with a Canadian Cross. This is because the newly 2060built target compiler will be a program which runs on the host system, 2061and therefore will not be able to run on the build system. 2062 2063 Therefore, when building a cross compiler with the Cygnus tree, you 2064must first install a set of build cross target tools. These tools will 2065be used when building the target libraries. 2066 2067 Note that this is not a requirement of a Canadian Cross in general. 2068For example, it would be possible to build just the host cross target 2069tools on the build system, to copy the tools to the host system, and to 2070build the target libraries on the host system. The requirement for 2071build cross target tools is imposed by the Cygnus tree, which expects 2072to be able to build both host programs and target libraries in a single 2073`configure'/`make' step. Because it builds these in a single step, it 2074expects to be able to build the target libraries on the build system, 2075which means that it must use a build cross target toolchain. 2076 2077 For example, suppose you want to build a Windows cross MIPS ELF 2078compiler on a GNU/Linux system. You must have previously installed 2079both a GNU/Linux cross Windows compiler and a GNU/Linux cross MIPS ELF 2080compiler. 2081 2082 In order to build the Windows (configuration name `i386-cygwin32') 2083cross MIPS ELF (configure name `mips-elf') compiler, you might execute 2084the following commands (long command lines are broken across lines with 2085a trailing backslash as a continuation character). 2086 2087 mkdir linux-x-cygwin32 2088 cd linux-x-cygwin32 2089 SRCDIR/configure --target i386-cygwin32 --prefix=INSTALLDIR \ 2090 --exec-prefix=INSTALLDIR/H-i386-linux 2091 make 2092 make install 2093 cd .. 2094 mkdir linux-x-mips-elf 2095 cd linux-x-mips-elf 2096 SRCDIR/configure --target mips-elf --prefix=INSTALLDIR \ 2097 --exec-prefix=INSTALLDIR/H-i386-linux 2098 make 2099 make install 2100 cd .. 2101 mkdir cygwin32-x-mips-elf 2102 cd cygwin32-x-mips-elf 2103 SRCDIR/configure --build=i386-linux-gnu --host=i386-cygwin32 \ 2104 --target=mips-elf --prefix=WININSTALLDIR \ 2105 --exec-prefix=WININSTALLDIR/H-i386-cygwin32 2106 make 2107 make install 2108 2109 You would then copy the contents of WININSTALLDIR over to the 2110Windows machine, and run the resulting programs. 2111 2112 2113File: configure.info, Node: Supporting Canadian Cross, Prev: CCross in Cygnus Tree, Up: Canadian Cross 2114 21156.7 Supporting Canadian Cross 2116============================= 2117 2118If you want to make it possible to build a program you are developing 2119using a Canadian Cross, you must take some care when writing your 2120configure and make rules. Simple cases will normally work correctly. 2121However, it is not hard to write configure and make tests which will 2122fail in a Canadian Cross. 2123 2124* Menu: 2125 2126* CCross in Configure:: Supporting Canadian Cross in Configure Scripts. 2127* CCross in Make:: Supporting Canadian Cross in Makefiles. 2128 2129 2130File: configure.info, Node: CCross in Configure, Next: CCross in Make, Up: Supporting Canadian Cross 2131 21326.7.1 Supporting Canadian Cross in Configure Scripts 2133---------------------------------------------------- 2134 2135In a `configure.in' file, after calling `AC_PROG_CC', you can find out 2136whether this is a Canadian Cross configure by examining the shell 2137variable `cross_compiling'. In a Canadian Cross, which means that the 2138compiler is a cross compiler, `cross_compiling' will be `yes'. In a 2139normal configuration, `cross_compiling' will be `no'. 2140 2141 You ordinarily do not need to know the type of the build system in a 2142configure script. However, if you do need that information, you can get 2143it by using the macro `AC_CANONICAL_SYSTEM', the same macro that is 2144used to determine the target system. This macro will set the variables 2145`build', `build_alias', `build_cpu', `build_vendor', and `build_os', 2146which correspond to the similar `target' and `host' variables, except 2147that they describe the build system. 2148 2149 When writing tests in `configure.in', you must remember that you 2150want to test the host environment, not the build environment. 2151 2152 Macros like `AC_CHECK_FUNCS' which use the compiler will test the 2153host environment. That is because the tests will be done by running the 2154compiler, which is actually a build cross host compiler. If the 2155compiler can find the function, that means that the function is present 2156in the host environment. 2157 2158 Tests like `test -f /dev/ptyp0', on the other hand, will test the 2159build environment. Remember that the configure script is running on the 2160build system, not the host system. If your configure scripts examines 2161files, those files will be on the build system. Whatever you determine 2162based on those files may or may not be the case on the host system. 2163 2164 Most autoconf macros will work correctly for a Canadian Cross. The 2165main exception is `AC_TRY_RUN'. This macro tries to compile and run a 2166test program. This will fail in a Canadian Cross, because the program 2167will be compiled for the host system, which means that it will not run 2168on the build system. 2169 2170 The `AC_TRY_RUN' macro provides an optional argument to tell the 2171configure script what to do in a Canadian Cross. If that argument is 2172not present, you will get a warning when you run `autoconf': 2173 warning: AC_TRY_RUN called without default to allow cross compiling 2174 This tells you that the resulting `configure' script will not work 2175with a Canadian Cross. 2176 2177 In some cases while it may better to perform a test at configure 2178time, it is also possible to perform the test at run time. In such a 2179case you can use the cross compiling argument to `AC_TRY_RUN' to tell 2180your program that the test could not be performed at configure time. 2181 2182 There are a few other autoconf macros which will not work correctly 2183with a Canadian Cross: a partial list is `AC_FUNC_GETPGRP', 2184`AC_FUNC_SETPGRP', `AC_FUNC_SETVBUF_REVERSED', and 2185`AC_SYS_RESTARTABLE_SYSCALLS'. The `AC_CHECK_SIZEOF' macro is 2186generally not very useful with a Canadian Cross; it permits an optional 2187argument indicating the default size, but there is no way to know what 2188the correct default should be. 2189 2190 2191File: configure.info, Node: CCross in Make, Prev: CCross in Configure, Up: Supporting Canadian Cross 2192 21936.7.2 Supporting Canadian Cross in Makefiles. 2194--------------------------------------------- 2195 2196The main Canadian Cross issue in a `Makefile' arises when you want to 2197use a subsidiary program to generate code or data which you will then 2198include in your real program. 2199 2200 If you compile this subsidiary program using `$(CC)' in the usual 2201way, you will not be able to run it. This is because `$(CC)' will 2202build a program for the host system, but the program is being built on 2203the build system. 2204 2205 You must instead use a compiler for the build system, rather than the 2206host system. In the Cygnus tree, this make variable `$(CC_FOR_BUILD)' 2207will hold a compiler for the build system. 2208 2209 Note that you should not include `config.h' in a file you are 2210compiling with `$(CC_FOR_BUILD)'. The `configure' script will build 2211`config.h' with information for the host system. However, you are 2212compiling the file using a compiler for the build system (a native 2213compiler). Subsidiary programs are normally simple filters which do no 2214user interaction, and it is normally possible to write them in a highly 2215portable fashion so that the absence of `config.h' is not crucial. 2216 2217 The gcc `Makefile.in' shows a complex situation in which certain 2218files, such as `rtl.c', must be compiled into both subsidiary programs 2219run on the build system and into the final program. This approach may 2220be of interest for advanced build system hackers. Note that the build 2221system compiler is rather confusingly called `HOST_CC'. 2222 2223 2224File: configure.info, Node: Cygnus Configure, Next: Multilibs, Prev: Canadian Cross, Up: Top 2225 22267 Cygnus Configure 2227****************** 2228 2229The Cygnus configure script predates autoconf. All of its interesting 2230features have been incorporated into autoconf. No new programs should 2231be written to use the Cygnus configure script. 2232 2233 However, the Cygnus configure script is still used in a few places: 2234at the top of the Cygnus tree and in a few target libraries in the 2235Cygnus tree. Until those uses have been replaced with autoconf, some 2236brief notes are appropriate here. This is not complete documentation, 2237but it should be possible to use this as a guide while examining the 2238scripts themselves. 2239 2240* Menu: 2241 2242* Cygnus Configure Basics:: Cygnus Configure Basics. 2243* Cygnus Configure in C++ Libraries:: Cygnus Configure in C++ Libraries. 2244 2245 2246File: configure.info, Node: Cygnus Configure Basics, Next: Cygnus Configure in C++ Libraries, Up: Cygnus Configure 2247 22487.1 Cygnus Configure Basics 2249=========================== 2250 2251Cygnus configure does not use any generated files; there is no program 2252corresponding to `autoconf'. Instead, there is a single shell script 2253named `configure' which may be found at the top of the Cygnus tree. 2254This shell script was written by hand; it was not generated by 2255autoconf, and it is incorrect, and indeed harmful, to run `autoconf' in 2256the top level of a Cygnus tree. 2257 2258 Cygnus configure works in a particular directory by examining the 2259file `configure.in' in that directory. That file is broken into four 2260separate shell scripts. 2261 2262 The first is the contents of `configure.in' up to a line that starts 2263with `# per-host:'. This is the common part. 2264 2265 The second is the rest of `configure.in' up to a line that starts 2266with `# per-target:'. This is the per host part. 2267 2268 The third is the rest of `configure.in' up to a line that starts 2269with `# post-target:'. This is the per target part. 2270 2271 The fourth is the remainder of `configure.in'. This is the post 2272target part. 2273 2274 If any of these comment lines are missing, the corresponding shell 2275script is empty. 2276 2277 Cygnus configure will first execute the common part. This must set 2278the shell variable `srctrigger' to the name of a source file, to 2279confirm that Cygnus configure is looking at the right directory. This 2280may set the shell variables `package_makefile_frag' and 2281`package_makefile_rules_frag'. 2282 2283 Cygnus configure will next set the `build' and `host' shell 2284variables, and execute the per host part. This may set the shell 2285variable `host_makefile_frag'. 2286 2287 Cygnus configure will next set the `target' variable, and execute 2288the per target part. This may set the shell variable 2289`target_makefile_frag'. 2290 2291 Any of these scripts may set the `subdirs' shell variable. This 2292variable is a list of subdirectories where a `Makefile.in' file may be 2293found. Cygnus configure will automatically look for a `Makefile.in' 2294file in the current directory. The `subdirs' shell variable is not 2295normally used, and I believe that the only directory which uses it at 2296present is `newlib'. 2297 2298 For each `Makefile.in', Cygnus configure will automatically create a 2299`Makefile' by adding definitions for `make' variables such as `host' 2300and `target', and automatically editing the values of `make' variables 2301such as `prefix' if they are present. 2302 2303 Also, if any of the `makefile_frag' shell variables are set, Cygnus 2304configure will interpret them as file names relative to either the 2305working directory or the source directory, and will read the contents of 2306the file into the generated `Makefile'. The file contents will be read 2307in after the first line in `Makefile.in' which starts with `####'. 2308 2309 These `Makefile' fragments are used to customize behaviour for a 2310particular host or target. They serve to select particular files to 2311compile, and to define particular preprocessor macros by providing 2312values for `make' variables which are then used during compilation. 2313Cygnus configure, unlike autoconf, normally does not do feature tests, 2314and normally requires support to be added manually for each new host. 2315 2316 The `Makefile' fragment support is similar to the autoconf 2317`AC_SUBST_FILE' macro. 2318 2319 After creating each `Makefile', the post target script will be run 2320(i.e., it may be run several times). This script may further customize 2321the `Makefile'. When it is run, the shell variable `Makefile' will 2322hold the name of the `Makefile', including the appropriate directory 2323component. 2324 2325 Like an autoconf generated `configure' script, Cygnus configure will 2326create a file named `config.status' which, when run, will automatically 2327recreate the configuration. The `config.status' file will simply 2328execute the Cygnus configure script again with the appropriate 2329arguments. 2330 2331 Any of the parts of `configure.in' may set the shell variables 2332`files' and `links'. Cygnus configure will set up symlinks from the 2333names in `links' to the files named in `files'. This is similar to the 2334autoconf `AC_LINK_FILES' macro. 2335 2336 Finally, any of the parts of `configure.in' may set the shell 2337variable `configdirs' to a set of subdirectories. If it is set, Cygnus 2338configure will recursively run the configure process in each 2339subdirectory. If the subdirectory uses Cygnus configure, it will 2340contain a `configure.in' file but no `configure' file, in which case 2341Cygnus configure will invoke itself recursively. If the subdirectory 2342has a `configure' file, Cygnus configure assumes that it is an autoconf 2343generated `configure' script, and simply invokes it directly. 2344 2345 2346File: configure.info, Node: Cygnus Configure in C++ Libraries, Prev: Cygnus Configure Basics, Up: Cygnus Configure 2347 23487.2 Cygnus Configure in C++ Libraries 2349===================================== 2350 2351The C++ library configure system, written by Per Bothner, deserves 2352special mention. It uses Cygnus configure, but it does feature testing 2353like that done by autoconf generated `configure' scripts. This 2354approach is used in the libraries `libio', `libstdc++', and `libg++'. 2355 2356 Most of the `Makefile' information is written out by the shell 2357script `libio/config.shared'. Each `configure.in' file sets certain 2358shell variables, and then invokes `config.shared' to create two package 2359`Makefile' fragments. These fragments are then incorporated into the 2360resulting `Makefile' by the Cygnus configure script. 2361 2362 The file `_G_config.h' is created in the `libio' object directory by 2363running the shell script `libio/gen-params'. This shell script uses 2364feature tests to define macros and typedefs in `_G_config.h'. 2365 2366 2367File: configure.info, Node: Multilibs, Next: FAQ, Prev: Cygnus Configure, Up: Top 2368 23698 Multilibs 2370*********** 2371 2372For some targets gcc may have different processor requirements depending 2373upon command line options. An obvious example is the `-msoft-float' 2374option supported on several processors. This option means that the 2375floating point registers are not available, which means that floating 2376point operations must be done by calling an emulation subroutine rather 2377than by using machine instructions. 2378 2379 For such options, gcc is often configured to compile target libraries 2380twice: once with `-msoft-float' and once without. When gcc compiles 2381target libraries more than once, the resulting libraries are called 2382"multilibs". 2383 2384 Multilibs are not really part of the GNU configure and build system, 2385but we discuss them here since they require support in the `configure' 2386scripts and `Makefile's used for target libraries. 2387 2388* Menu: 2389 2390* Multilibs in gcc:: Multilibs in gcc. 2391* Multilibs in Target Libraries:: Multilibs in Target Libraries. 2392 2393 2394File: configure.info, Node: Multilibs in gcc, Next: Multilibs in Target Libraries, Up: Multilibs 2395 23968.1 Multilibs in gcc 2397==================== 2398 2399In gcc, multilibs are defined by setting the variable 2400`MULTILIB_OPTIONS' in the target `Makefile' fragment. Several other 2401`MULTILIB' variables may also be defined there. *Note The Target 2402Makefile Fragment: (gcc)Target Fragment. 2403 2404 If you have built gcc, you can see what multilibs it uses by running 2405it with the `-print-multi-lib' option. The output `.;' means that no 2406multilibs are used. In general, the output is a sequence of lines, one 2407per multilib. The first part of each line, up to the `;', is the name 2408of the multilib directory. The second part is a list of compiler 2409options separated by `@' characters. 2410 2411 Multilibs are built in a tree of directories. The top of the tree, 2412represented by `.' in the list of multilib directories, is the default 2413library to use when no special compiler options are used. The 2414subdirectories of the tree hold versions of the library to use when 2415particular compiler options are used. 2416 2417 2418File: configure.info, Node: Multilibs in Target Libraries, Prev: Multilibs in gcc, Up: Multilibs 2419 24208.2 Multilibs in Target Libraries 2421================================= 2422 2423The target libraries in the Cygnus tree are automatically built with 2424multilibs. That means that each library is built multiple times. 2425 2426 This default is set in the top level `configure.in' file, by adding 2427`--enable-multilib' to the list of arguments passed to configure when 2428it is run for the target libraries (*note Host and Target Libraries::). 2429 2430 Each target library uses the shell script `config-ml.in', written by 2431Doug Evans, to prepare to build target libraries. This shell script is 2432invoked after the `Makefile' has been created by the `configure' 2433script. If multilibs are not enabled, it does nothing, otherwise it 2434modifies the `Makefile' to support multilibs. 2435 2436 The `config-ml.in' script makes one copy of the `Makefile' for each 2437multilib in the appropriate subdirectory. When configuring in the 2438source directory (which is not recommended), it will build a symlink 2439tree of the sources in each subdirectory. 2440 2441 The `config-ml.in' script sets several variables in the various 2442`Makefile's. The `Makefile.in' must have definitions for these 2443variables already; `config-ml.in' simply changes the existing values. 2444The `Makefile' should use default values for these variables which will 2445do the right thing in the subdirectories. 2446 2447`MULTISRCTOP' 2448 `config-ml.in' will set this to a sequence of `../' strings, where 2449 the number of strings is the number of multilib levels in the 2450 source tree. The default value should be the empty string. 2451 2452`MULTIBUILDTOP' 2453 `config-ml.in' will set this to a sequence of `../' strings, where 2454 the number of strings is number of multilib levels in the object 2455 directory. The default value should be the empty string. This 2456 will differ from `MULTISRCTOP' when configuring in the source tree 2457 (which is not recommended). 2458 2459`MULTIDIRS' 2460 In the top level `Makefile' only, `config-ml.in' will set this to 2461 the list of multilib subdirectories. The default value should be 2462 the empty string. 2463 2464`MULTISUBDIR' 2465 `config-ml.in' will set this to the installed subdirectory name to 2466 use for this subdirectory, with a leading `/'. The default value 2467 shold be the empty string. 2468 2469`MULTIDO' 2470`MULTICLEAN' 2471 In the top level `Makefile' only, `config-ml.in' will set these 2472 variables to commands to use when doing a recursive make. These 2473 variables should both default to the string `true', so that by 2474 default nothing happens. 2475 2476 All references to the parent of the source directory should use the 2477variable `MULTISRCTOP'. Instead of writing `$(srcdir)/..', you must 2478write `$(srcdir)/$(MULTISRCTOP)..'. 2479 2480 Similarly, references to the parent of the object directory should 2481use the variable `MULTIBUILDTOP'. 2482 2483 In the installation target, the libraries should be installed in the 2484subdirectory `MULTISUBDIR'. Instead of installing 2485`$(libdir)/libfoo.a', install `$(libdir)$(MULTISUBDIR)/libfoo.a'. 2486 2487 The `config-ml.in' script also modifies the top level `Makefile' to 2488add `multi-do' and `multi-clean' targets which are used when building 2489multilibs. 2490 2491 The default target of the `Makefile' should include the following 2492command: 2493 @$(MULTIDO) $(FLAGS_TO_PASS) DO=all multi-do 2494 This assumes that `$(FLAGS_TO_PASS)' is defined as a set of 2495variables to pass to a recursive invocation of `make'. This will build 2496all the multilibs. Note that the default value of `MULTIDO' is `true', 2497so by default this command will do nothing. It will only do something 2498in the top level `Makefile' if multilibs were enabled. 2499 2500 The `install' target of the `Makefile' should include the following 2501command: 2502 @$(MULTIDO) $(FLAGS_TO_PASS) DO=install multi-do 2503 2504 In general, any operation, other than clean, which should be 2505performed on all the multilibs should use a `$(MULTIDO)' line, setting 2506the variable `DO' to the target of each recursive call to `make'. 2507 2508 The `clean' targets (`clean', `mostlyclean', etc.) should use 2509`$(MULTICLEAN)'. For example, the `clean' target should do this: 2510 @$(MULTICLEAN) DO=clean multi-clean 2511 2512 2513File: configure.info, Node: FAQ, Next: Index, Prev: Multilibs, Up: Top 2514 25159 Frequently Asked Questions 2516**************************** 2517 2518Which do I run first, `autoconf' or `automake'? 2519 Except when you first add autoconf or automake support to a 2520 package, you shouldn't run either by hand. Instead, configure 2521 with the `--enable-maintainer-mode' option, and let `make' take 2522 care of it. 2523 2524`autoconf' says something about undefined macros. 2525 This means that you have macros in your `configure.in' which are 2526 not defined by `autoconf'. You may be using an old version of 2527 `autoconf'; try building and installing a newer one. Make sure the 2528 newly installled `autoconf' is first on your `PATH'. Also, see 2529 the next question. 2530 2531My `configure' script has stuff like `CY_GNU_GETTEXT' in it. 2532 This means that you have macros in your `configure.in' which should 2533 be defined in your `aclocal.m4' file, but aren't. This usually 2534 means that `aclocal' was not able to appropriate definitions of the 2535 macros. Make sure that you have installed all the packages you 2536 need. In particular, make sure that you have installed libtool 2537 (this is where `AM_PROG_LIBTOOL' is defined) and gettext (this is 2538 where `CY_GNU_GETTEXT' is defined, at least in the Cygnus version 2539 of gettext). 2540 2541My `Makefile' has `@' characters in it. 2542 This may mean that you tried to use an autoconf substitution in 2543 your `Makefile.in' without adding the appropriate `AC_SUBST' call 2544 to your `configure' script. Or it may just mean that you need to 2545 rebuild `Makefile' in your build directory. To rebuild `Makefile' 2546 from `Makefile.in', run the shell script `config.status' with no 2547 arguments. If you need to force `configure' to run again, first 2548 run `config.status --recheck'. These runs are normally done 2549 automatically by `Makefile' targets, but if your `Makefile' has 2550 gotten messed up you'll need to help them along. 2551 2552Why do I have to run both `config.status --recheck' and `config.status'? 2553 Normally, you don't; they will be run automatically by `Makefile' 2554 targets. If you do need to run them, use `config.status --recheck' 2555 to run the `configure' script again with the same arguments as the 2556 first time you ran it. Use `config.status' (with no arguments) to 2557 regenerate all files (`Makefile', `config.h', etc.) based on the 2558 results of the configure script. The two cases are separate 2559 because it isn't always necessary to regenerate all the files 2560 after running `config.status --recheck'. The `Makefile' targets 2561 generated by automake will use the environment variables 2562 `CONFIG_FILES' and `CONFIG_HEADERS' to only regenerate files as 2563 they are needed. 2564 2565What is the Cygnus tree? 2566 The Cygnus tree is used for various packages including gdb, the GNU 2567 binutils, and egcs. It is also, of course, used for Cygnus 2568 releases. It is the build system which was developed at Cygnus, 2569 using the Cygnus configure script. It permits building many 2570 different packages with a single configure and make. The 2571 configure scripts in the tree are being converted to autoconf, but 2572 the general build structure remains intact. 2573 2574Why do I have to keep rebuilding and reinstalling the tools? 2575 I know, it's a pain. Unfortunately, there are bugs in the tools 2576 themselves which need to be fixed, and each time that happens 2577 everybody who uses the tools need to reinstall new versions of 2578 them. I don't know if there is going to be a clever fix until the 2579 tools stabilize. 2580 2581Why not just have a Cygnus tree `make' target to update the tools? 2582 The tools unfortunately need to be installed before they can be 2583 used. That means that they must be built using an appropriate 2584 prefix, and it seems unwise to assume that every configuration 2585 uses an appropriate prefix. It might be possible to make them 2586 work in place, or it might be possible to install them in some 2587 subdirectory; so far these approaches have not been implemented. 2588 2589 2590File: configure.info, Node: Index, Prev: FAQ, Up: Top 2591 2592Index 2593***** 2594 2595�[index�] 2596* Menu: 2597 2598* --build option: Build and Host Options. 2599 (line 9) 2600* --host option: Build and Host Options. 2601 (line 14) 2602* --target option: Specifying the Target. 2603 (line 10) 2604* _GNU_SOURCE: Write configure.in. (line 134) 2605* AC_CANONICAL_HOST: Using the Host Type. (line 10) 2606* AC_CANONICAL_SYSTEM: Using the Target Type. 2607 (line 6) 2608* AC_CONFIG_HEADER: Write configure.in. (line 66) 2609* AC_EXEEXT: Write configure.in. (line 86) 2610* AC_INIT: Write configure.in. (line 38) 2611* AC_OUTPUT: Write configure.in. (line 142) 2612* AC_PREREQ: Write configure.in. (line 42) 2613* AC_PROG_CC: Write configure.in. (line 103) 2614* AC_PROG_CXX: Write configure.in. (line 117) 2615* acconfig.h: Written Developer Files. 2616 (line 27) 2617* acconfig.h, writing: Write acconfig.h. (line 6) 2618* acinclude.m4: Written Developer Files. 2619 (line 37) 2620* aclocal.m4: Generated Developer Files. 2621 (line 33) 2622* AM_CONFIG_HEADER: Write configure.in. (line 53) 2623* AM_DISABLE_SHARED: Write configure.in. (line 127) 2624* AM_EXEEXT: Write configure.in. (line 86) 2625* AM_INIT_AUTOMAKE: Write configure.in. (line 48) 2626* AM_MAINTAINER_MODE: Write configure.in. (line 70) 2627* AM_PROG_LIBTOOL: Write configure.in. (line 122) 2628* AM_PROG_LIBTOOL in configure: FAQ. (line 19) 2629* build option: Build and Host Options. 2630 (line 9) 2631* building with a cross compiler: Canadian Cross. (line 6) 2632* canadian cross: Canadian Cross. (line 6) 2633* canadian cross in configure: CCross in Configure. (line 6) 2634* canadian cross in cygnus tree: CCross in Cygnus Tree. 2635 (line 6) 2636* canadian cross in makefile: CCross in Make. (line 6) 2637* canadian cross, configuring: Build and Host Options. 2638 (line 6) 2639* canonical system names: Configuration Names. (line 6) 2640* config.cache: Build Files Description. 2641 (line 28) 2642* config.h: Build Files Description. 2643 (line 23) 2644* config.h.in: Generated Developer Files. 2645 (line 45) 2646* config.in: Generated Developer Files. 2647 (line 45) 2648* config.status: Build Files Description. 2649 (line 9) 2650* config.status --recheck: FAQ. (line 40) 2651* configuration names: Configuration Names. (line 6) 2652* configuration triplets: Configuration Names. (line 6) 2653* configure: Generated Developer Files. 2654 (line 21) 2655* configure build system: Build and Host Options. 2656 (line 9) 2657* configure host: Build and Host Options. 2658 (line 14) 2659* configure target: Specifying the Target. 2660 (line 10) 2661* configure.in: Written Developer Files. 2662 (line 9) 2663* configure.in, writing: Write configure.in. (line 6) 2664* configuring a canadian cross: Build and Host Options. 2665 (line 6) 2666* cross compiler: Cross Compilation Concepts. 2667 (line 6) 2668* cross compiler, building with: Canadian Cross. (line 6) 2669* cross tools: Cross Compilation Tools. 2670 (line 6) 2671* CY_GNU_GETTEXT in configure: FAQ. (line 19) 2672* cygnus configure: Cygnus Configure. (line 6) 2673* goals: Goals. (line 6) 2674* history: History. (line 6) 2675* host names: Configuration Names. (line 6) 2676* host option: Build and Host Options. 2677 (line 14) 2678* host system: Host and Target. (line 6) 2679* host triplets: Configuration Names. (line 6) 2680* HOST_CC: CCross in Make. (line 27) 2681* libg++ configure: Cygnus Configure in C++ Libraries. 2682 (line 6) 2683* libio configure: Cygnus Configure in C++ Libraries. 2684 (line 6) 2685* libstdc++ configure: Cygnus Configure in C++ Libraries. 2686 (line 6) 2687* Makefile: Build Files Description. 2688 (line 18) 2689* Makefile, garbage characters: FAQ. (line 29) 2690* Makefile.am: Written Developer Files. 2691 (line 18) 2692* Makefile.am, writing: Write Makefile.am. (line 6) 2693* Makefile.in: Generated Developer Files. 2694 (line 26) 2695* multilibs: Multilibs. (line 6) 2696* stamp-h: Build Files Description. 2697 (line 41) 2698* stamp-h.in: Generated Developer Files. 2699 (line 54) 2700* system names: Configuration Names. (line 6) 2701* system types: Configuration Names. (line 6) 2702* target option: Specifying the Target. 2703 (line 10) 2704* target system: Host and Target. (line 6) 2705* triplets: Configuration Names. (line 6) 2706* undefined macros: FAQ. (line 12) 2707 2708 2709 2710Tag Table: 2711Node: Top978 2712Node: Introduction1506 2713Node: Goals2588 2714Node: Tools3312 2715Node: History4306 2716Node: Building7304 2717Node: Getting Started10399 2718Node: Write configure.in10912 2719Node: Write Makefile.am18163 2720Node: Write acconfig.h21340 2721Node: Generate files22877 2722Node: Getting Started Example24843 2723Node: Getting Started Example 125598 2724Node: Getting Started Example 227519 2725Node: Getting Started Example 330514 2726Node: Generate Files in Example32878 2727Node: Files33968 2728Node: Developer Files34579 2729Node: Developer Files Picture34959 2730Node: Written Developer Files36247 2731Node: Generated Developer Files38799 2732Node: Build Files41943 2733Node: Build Files Picture42604 2734Node: Build Files Description43368 2735Node: Support Files45374 2736Node: Configuration Names48256 2737Node: Configuration Name Definition48756 2738Node: Using Configuration Names51079 2739Node: Cross Compilation Tools53049 2740Node: Cross Compilation Concepts53740 2741Node: Host and Target54708 2742Node: Using the Host Type56209 2743Node: Specifying the Target57558 2744Node: Using the Target Type58347 2745Node: Cross Tools in the Cygnus Tree61778 2746Node: Host and Target Libraries62835 2747Node: Target Library Configure Scripts66584 2748Node: Make Targets in Cygnus Tree69676 2749Node: Target libiberty71024 2750Node: Canadian Cross72411 2751Node: Canadian Cross Example73252 2752Node: Canadian Cross Concepts74371 2753Node: Build Cross Host Tools75883 2754Node: Build and Host Options76835 2755Node: CCross not in Cygnus Tree78621 2756Node: CCross in Cygnus Tree79599 2757Node: Standard Cygnus CCross80020 2758Node: Cross Cygnus CCross81384 2759Node: Supporting Canadian Cross84184 2760Node: CCross in Configure84799 2761Node: CCross in Make87967 2762Node: Cygnus Configure89570 2763Node: Cygnus Configure Basics90405 2764Node: Cygnus Configure in C++ Libraries95083 2765Node: Multilibs96090 2766Node: Multilibs in gcc97135 2767Node: Multilibs in Target Libraries98213 2768Node: FAQ102404 2769Node: Index106504 2770 2771End Tag Table 2772