alent to `-C /etc'. This is typically used with recursive invocations of `make' (*note Recursive Use of `make': Recursion.). `-d' Print debugging information in addition to normal processing. The debugging information says which files are being considered for remaking, which file-times are being compared and with what results, which files actually need to be remade, which implicit rules are considered and which are applied--everything interesting about how `make' decides what to do. The `-d' option is equivalent to `--debug=a' (see below). `--debug[=OPTIONS]' Print debugging information in addition to normal processing. Various levels and types of output can be chosen. With no arguments, print the "basic" level of debugging. Possible arguments are below; only the first character is considered, and values must be comma- or space-separated. `a (all)' All types of debugging output are enabled. This is equivalent to using `-d'. `b (basic)' Basic debugging prints each target that was found to be out-of-date, and whether the build was successful or not. `v (verbose)' A level above `basic'; includes messages about which makefiles were parsed, prerequisites that did not need to be rebuilt, etc. This option also enables `basic' messages. `i (implicit)' Prints messages describing the implicit rule searches for each target. This option also enables `basic' messages. `j (jobs)' Prints messages giving details on the invocation of specific subcommands. `m (makefile)' By default, the above messages are not enabled while trying to remake the makefiles. This option enables messages while rebuilding makefiles, too. Note that the `all' option does enable this option. This option also enables `basic' messages. `-e' `--environment-overrides' Give variables taken from the environment precedence over variables from makefiles. *Note Variables from the Environment: Environment. `-f FILE' `--file=FILE' `--makefile=FILE' Read the file named FILE as a makefile. *Note Writing Makefiles: Makefiles. `-h' `--help' Remind you of the options that `make' understands and then exit. `-i' `--ignore-errors' Ignore all errors in commands executed to remake files. *Note Errors in Commands: Errors. `-I DIR' `--include-dir=DIR' Specifies a directory DIR to search for included makefiles. *Note Including Other Makefiles: Include. If several `-I' options are used to specify several directories, the directories are searched in the order specified. `-j [JOBS]' `--jobs[=JOBS]' Specifies the number of jobs (commands) to run simultaneously. With no argument, `make' runs as many jobs simultaneously as possible. If there is more than one `-j' option, the last one is effective. *Note Parallel Execution: Parallel, for more information on how commands are run. Note that this option is ignored on MS-DOS. `-k' `--keep-going' Continue as much as possible after an error. While the target that failed, and those that depend on it, cannot be remade, the other prerequisites of these targets can be processed all the same. *Note Testing the Compilation of a Program: Testing. `-l [LOAD]' `--load-average[=LOAD]' `--max-load[=LOAD]' Specifies that no new jobs (commands) should be started if there are other jobs running and the load average is at least LOAD (a floating-point number). With no argument, removes a previous load limit. *Note Parallel Execution: Parallel. `-L' `--check-symlink-times' On systems that support symbolic links, this option causes `make' to consider the timestamps on any symbolic links in addition to the timestamp on the file referenced by those links. When this option is provided, the most recent timestamp among the file and the symbolic links is taken as the modification time for this target file. `-n' `--just-print' `--dry-run' `--recon' Print the commands that would be executed, but do not execute them. *Note Instead of Executing the Commands: Instead of Execution. `-o FILE' `--old-file=FILE' `--assume-old=FILE' Do not remake the file FILE even if it is older than its prerequisites, and do not remake anything on account of changes in FILE. Essentially the file is treated as very old and its rules are ignored. *Note Avoiding Recompilation of Some Files: Avoiding Compilation. `-p' `--print-data-base' Print the data base (rules and variable values) that results from reading the makefiles; then execute as usual or as otherwise specified. This also prints the version information given by the `-v' switch (see below). To print the data base without trying to remake any files, use `make -qp'. To print the data base of predefined rules and variables, use `make -p -f /dev/null'. The data base output contains filename and linenumber information for command and variable definitions, so it can be a useful debugging tool in complex environments. `-q' `--question' "Question mode". Do not run any commands, or print anything; just return an exit status that is zero if the specified targets are already up to date, one if any remaking is required, or two if an error is encountered. *Note Instead of Executing the Commands: Instead of Execution. `-r' `--no-builtin-rules' Eliminate use of the built-in implicit rules (*note Using Implicit Rules: Implicit Rules.). You can still define your own by writing pattern rules (*note Defining and Redefining Pattern Rules: Pattern Rules.). The `-r' option also clears out the default list of suffixes for suffix rules (*note Old-Fashioned Suffix Rules: Suffix Rules.). But you can still define your own suffixes with a rule for `.SUFFIXES', and then define youG™H™I™J™K™L™M™N™O™P™Q™R™S™T™U™V™W™X™Y™Z™[™\™]™^™_™`™a™b™r own suffix rules. Note that only _rules_ are affected by the `-r' option; default variables remain in effect (*note Variables Used by Implicit Rules: Implicit Variables.); see the `-R' option below. `-R' `--no-builtin-variables' Eliminate use of the built-in rule-specific variables (*note Variables Used by Implicit Rules: Implicit Variables.). You can still define your own, of course. The `-R' option also automatically enables the `-r' option (see above), since it doesn't make sense to have implicit rules without any definitions for the variables that they use. `-s' `--silent' `--quiet' Silent operation; do not print the commands as they are executed. *Note Command Echoing: Echoing. `-S' `--no-keep-going' `--stop' Cancel the effect of the `-k' option. This is never necessary except in a recursive `make' where `-k' might be inherited from the top-level `make' via `MAKEFLAGS' (*note Recursive Use of `make': Recursion.) or if you set `-k' in `MAKEFLAGS' in your environment. `-t' `--touch' Touch files (mark them up to date without really changing them) instead of running their commands. This is used to pretend that the commands were done, in order to fool future invocations of `make'. *Note Instead of Executing the Commands: Instead of Execution. `-v' `--version' Print the version of the `make' program plus a copyright, a list of authors, and a notice that there is no warranty; then exit. `-w' `--print-directory' Print a message containing the working directory both before and after executing the makefile. This may be useful for tracking down errors from complicated nests of recursive `make' commands. *Note Recursive Use of `make': Recursion. (In practice, you rarely need to specify this option since `make' does it for you; see *Note The `--print-directory' Option: -w Option.) `--no-print-directory' Disable printing of the working directory under `-w'. This option is useful when `-w' is turned on automatically, but you do not want to see the extra messages. *Note The `--print-directory' Option: -w Option. `-W FILE' `--what-if=FILE' `--new-file=FILE' `--assume-new=FILE' Pretend that the target FILE has just been modified. When used with the `-n' flag, this shows you what would happen if you were to modify that file. Without `-n', it is almost the same as running a `touch' command on the given file before running `make', except that the modification time is changed only in the imagination of `make'. *Note Instead of Executing the Commands: Instead of Execution. `--warn-undefined-variables' Issue a warning message whenever `make' sees a reference to an undefined variable. This can be helpful when you are trying to debug makefiles which use variables in complex ways.  File: make.info, Node: Implicit Rules, Next: Archives, Prev: Running, Up: Top 10 Using Implicit Rules *********************** Certain standard ways of remaking target files are used very often. For example, one customary way to make an object file is from a C source file using the C compiler, `cc'. "Implicit rules" tell `make' how to use customary techniques so that you do not have to specify them in detail when you want to use them. For example, there is an implicit rule for C compilation. File names determine which implicit rules are run. For example, C compilation typically takes a `.c' file and makes a `.o' file. So `make' applies the implicit rule for C compilation when it sees this combination of file name endings. A chain of implicit rules can apply in sequence; for example, `make' will remake a `.o' file from a `.y' file by way of a `.c' file. The built-in implicit rules use several variables in their commands so that, by changing the values of the variables, you can change the way the implicit rule works. For example, the variable `CFLAGS' controls the flags given to the C compiler by the implicit rule for C compilation. You can define your own implicit rules by writing "pattern rules". "Suffix rules" are a more limited way to define implicit rules. Pattern rules are more general and clearer, but suffix rules are retained for compatibility. * Menu: * Using Implicit:: How to use an existing implicit rule to get the commands for updating a file. * Catalogue of Rules:: A list of built-in implicit rules. * Implicit Variables:: How to change what predefined rules do. * Chained Rules:: How to use a chain of implicit rules. * Pattern Rules:: How to define new implicit rules. * Last Resort:: How to define commands for rules which cannot find any. * Suffix Rules:: The old-fashioned style of implicit rule. * Implicit Rule Search:: The precise algorithm for applying implicit rules.  File: make.info, Node: Using Implicit, Next: Catalogue of Rules, Prev: Implicit Rules, Up: Implicit Rules 10.1 Using Implicit Rules ========================= To allow `make' to find a customary method for updating a target file, all you have to do is refrain from specifying commands yourself. Either write a rule with no command lines, or don't write a rule at all. Then `make' will figure out which implicit rule to use based on which kind of source file exists or can be made. For example, suppose the makefile looks like this: foo : foo.o bar.o cc -o foo foo.o bar.o $(CFLAGS) $(LDFLAGS) Because you mention `foo.o' but do not give a rule for it, `make' will automatically look for an implicit rule that tells how to update it. This happens whether or not the file `foo.o' currently exists. If an implicit rule is found, it can supply both commands and one or more prerequisites (the source files). You would want to write a rule for `foo.o' with no command lines if you need to specify additional prerequisites, such as header files, that the implicit rule cannot supply. Each implicit rule has a target pattern and prerequisite patterns. There may be many implicit rules with the same target pattern. For example, numerous rules make `.o' files: one, from a `.c' file with the C compiler; another, from a `.p' file with the Pascal compiler; and so on. The rule that actually applies is the one whose prerequisites exist or can be made. So, if you have a file `foo.c', `make' will run the C compiler; otherwise, if you have a file `foo.p', `make' will run the Pascal compiler; and so on. Of course, when you write the makefile, you know which implicit rule you want `make' to use, and you know it will choose that one because you know which possible prerequisite files are supposed to exist. *Note Catalogue of Implicit Rules: Catalogue of Rules, for a catalogue of all the predefined implicit rules. Above, we said an implicit rule applies if the required prerequisites "exist or can be made". A file "can be made" if it is mentioned explicitly in the makefile as a target or a prerequisite, or if an implicit rule can be recursively found for how to make it. When an implicit prerequisite is the result of another implicit rule, we say that "chaining" is occurring. *Note Chains of Implicit Rules: Chained Rules. In general, `make' searches for an implicit rule for each target, and for each double-colon rule, that has no commands. A file that is mentioned only as a prerequisite is considered a target whose rule specifies nothing, so implicit rule search happens for it. *Note Implicit Rule Search Algorithm: Implicit Rule Search, for the details of how the search is done. Note that explicit prerequisites do not influence implicit rule search. For example, consider this explicit rule: foo.o: foo.p The prerequisite on `foo.p' does not necessarily mean that `make' will remake `foo.o' according to the implicit rule to make an object file, a `.o' file, from a Pascal source file, a `.p' file. For example, if `foo.c' also exists, the implicit rule to make an object file from a C source file is used instead, because it appears before the Pascal rule in the list of predefined implicit rules (*note Catalogue of Implicit Rules: Catalogue of Rules.). If you do not want an implicit rule to be used for a target that has no commands, you can give that target empty commands by writing a semicolon (*note Defining Empty Commands: Empty Commands.).  File: make.info, Node: Catalogue of Rules, Next: Implicit Variables, Prev: Using Implicit, Up: Implicit Rules 10.2 Catalogue of Implicit Rules ================================ Here is a catalogue of predefined implicit rules which are always available unless the makefile explicitly overrides or cancels them. *Note Canceling Implicit Rules: Canceling Rules, for information on canceling or overriding an implicit rule. The `-r' or `--no-builtin-rules' option cancels all predefined rules. This manual only documents the default rules available on POSIX-based operating systems. Other operating systems, such as VMS, Windows, OS/2, etc. may have different sets of default rules. To see the full list of default rules and variables available in your version of GNU `make', run `make -p' in a directory with no makefile. Not all of these rules will always be defined, even when the `-r' option is not given. Many of the predefined implicit rules are implemented in `make' as suffix rules, so which ones will be defined depends on the "suffix list" (the list of prerequisites of the special target `.SUFFIXES'). The default suffix list is: `.out', `.a', `.ln', `.o', `.c', `.cc', `.C', `.cpp', `.p', `.f', `.F', `.r', `.y', `.l', `.s', `.S', `.mod', `.sym', `.def', `.h', `.info', `.dvi', `.tex', `.texinfo', `.texi', `.txinfo', `.w', `.ch' `.web', `.sh', `.elc', `.el'. All of the implicit rules described below whose prerequisites have one of these suffixes are actually suffix rules. If you modify the suffix list, the only predefined suffix rules in effect will be those named by one or two of the suffixes that are on the list you specify; rules whose suffixes fail to be on the list are disabled. *Note Old-Fashioned Suffix Rules: Suffix Rules, for full details on suffix rules. Compiling C programs `N.o' is made automatically from `N.c' with a command of the form `$(CC) -c $(CPPFLAGS) $(CFLAGS)'. Compiling C++ programs `N.o' is made automatically from `N.cc', `N.cpp', or `N.C' with a command of the form `$(CXX) -c $(CPPFLAGS) $(CXXFLAGS)'. We encourage you to use the suffix `.cc' for C++ source files instead of `.C'. Compiling Pascal programs `N.o' is made automatically from `N.p' with the command `$(PC) -c $(PFLAGS)'. Compiling Fortran and Ratfor programs `N.o' is made automatically from `N.r', `N.F' or `N.f' by running the Fortran compiler. The precise command used is as follows: `.f' `$(FC) -c $(FFLAGS)'. `.F' `$(FC) -c $(FFLAGS) $(CPPFLAGS)'. `.r' `$(FC) -c $(FFLAGS) $(RFLAGS)'. Preprocessing Fortran and Ratfor programs `N.f' is made automatically from `N.r' or `N.F'. This rule runs just the preprocessor to convert a Ratfor or preprocessable Fortran program into a strict Fortran program. The precise command used is as follows: `.F' `$(FC) -F $(CPPFLAGS) $(FFLAGS)'. `.r' `$(FC) -F $(FFLAGS) $(RFLAGS)'. Compiling Modula-2 programs `N.sym' is made from `N.def' with a command of the form `$(M2C) $(M2FLAGS) $(DEFFLAGS)'. `N.o' is made from `N.mod'; the form is: `$(M2C) $(M2FLAGS) $(MODFLAGS)'. Assembling and preprocessing assembler programs `N.o' is made automatically from `N.s' by running the assembler, `as'. The precise command is `$(AS) $(ASFLAGS)'. `N.s' is made automatically from `N.S' by running the C preprocessor, `cpp'. The precise command is `$(CPP) $(CPPFLAGS)'. Linking a single object file `N' is made automatically from `N.o' by running the linker (usually called `ld') via the C compiler. The precise command used is `$(CC) $(LDFLAGS) N.o $(LOADLIBES) $(LDLIBS)'. This rule does the right thing for a simple program with only one source file. It will also do the right thing if there are multiple object files (presumably coming from various other source files), one of which has a name matching that of the executable file. Thus, x: y.o z.o when `x.c', `y.c' and `z.c' all exist will execute: cc -c x.c -o x.o cc -c y.c -o y.o cc -c z.c -o z.o cc x.o y.o z.o -o x rm -f x.o rm -f y.o rm -f z.o In more complicated cases, such as when there is no object file whose name derives from the executable file name, you must write an explicit command for linking. Each kind of file automatically made into `.o' object files will be automatically linked by using the compiler (`$(CC)', `$(FC)' or `$(PC)'; the C compiler `$(CC)' is used to assemble `.s' files) without the `-c' option. This could be done by using the `.o' object files as intermediates, but it is faster to do the compiling and linking in one step, so that's how it's done. Yacc for C programs `N.c' is made automatically from `N.y' by running Yacc with the command `$(YACC) $(YFLAGS)'. Lex for C programs `N.c' is made automatically from `N.l' by running Lex. The actual command is `$(LEX) $(LFLAGS)'. Lex for Ratfor programs `N.r' is made automatically from `N.l' by running Lex. The actual command is `$(LEX) $(LFLAGS)'. The convention of using the same suffix `.l' for all Lex files regardless of whether they produce C code or Ratfor code makes it impossible for `make' to determine automatically which of the two languages you are using in any particular case. If `make' is called upon to remake an object file from a `.l' file, it must guess which compiler to use. It will guess the C compiler, because that is more common. If you are using Ratfor, make sure `make' knows this by mentioning `N.r' in the makefile. Or, if you are using Ratfor exclusively, with no C files, remove `.c' from the list of implicit rule suffixes with: .SUFFIXES: .SUFFIXES: .o .r .f .l ... Making Lint Libraries from C, Yacc, or Lex programs `N.ln' is made from `N.c' by running `lint'. The precise command is `$(LINT) $(LINTFLAGS) $(CPPFLAGS) -i'. The same command is used on the C code produced from `N.y' or `N.l'. TeX and Web `N.dvi' is made from `N.tex' with the command `$(TEX)'. `N.tex' is made from `N.web' with `$(WEAVE)', or from `N.w' (and from `N.ch' if it exists or can be made) with `$(CWEAVE)'. `N.p' is made from `N.web' with `$(TANGLE)' and `N.c' is made from `N.w' (and from `N.ch' if it exists or can be made) with `$(CTANGLE)'. Texinfo and Info `N.dvi' is made from `N.texinfo', `N.texi', or `N.txinfo', with the command `$(TEXI2DVI) $(TEXI2DVI_FLAGS)'. `N.info' is made from `N.texinfo', `N.texi', or `N.txinfo', with the command `$(MAKEINFO) $(MAKEINFO_FLAGS)'. RCS Any file `N' is extracted if necessary from an RCS file named either `N,v' or `RCS/N,v'. The precise command used is `$(CO) $(COFLAGS)'. `N' will not be extracted from RCS if it already exists, even if the RCS file is newer. The rules for RCS are terminal (*note Match-Anything Pattern Rules: Match-Anything Rules.), so RCS files cannot be generated from another source; they must actually exist. SCCS Any file `N' is extracted if necessary from an SCCS file named either `s.N' or `SCCS/s.N'. The precise command used is `$(GET) $(GFLAGS)'. The rules for SCCS are terminal (*note Match-Anything Pattern Rules: Match-Anything Rules.), so SCCS files cannot be generated from another source; they must actually exist. For the benefit of SCCS, a file `N' is copied from `N.sh' and made executable (by everyone). This is for shell scripts that are checked into SCCS. Since RCS preserves the execution permission of a file, you do not need to use this feature with RCS. We recommend that you avoid using of SCCS. RCS is widely held to be superior, and is also free. By choosing free software in place of comparable (or inferior) proprietary software, you support the free software movement. Usually, you want to change only the variables listed in the table above, which are documented in the following section. However, the commands in built-in implicit rules actually use variables such as `COMPILE.c', `LINK.p', and `PREPROCESS.S', whose values contain the commands listed above. `make' follows the convention that the rule to compile a `.X' source file uses the variable `COMPILE.X'. Similarly, the rule to produce an executable from a `.X' file uses `LINK.X'; and the rule to preprocess a `.X' file uses `PREPROCESS.X'. Every rule that produces an object file uses the variable `OUTPUT_OPTION'. `make' defines this variable either to contain `-o $@', or to be empty, depending on a compile-time option. You need the `-o' option to ensure that the output goes into the right file when the source file is in a different directory, as when using `VPATH' (*note Directory Search::). However, compilers on some systems do not accept a `-o' switch for object files. If you use such a system, and use `VPATH', some compilations will put their output in the wrong place. A possible workaround for this problem is to give `OUTPUT_OPTION' the value `; mv $*.o $@'.  File: make.info, Node: Implicit Variables, Next: Chained Rules, Prev: Catalogue of Rules, Up: Implicit Rules 10.3 Variables Used by Implicit Rules ===================================== The commands in built-in implicit rules make liberal use of certain predefined variables. You can alter the values of these variables in the makefile, with arguments to `make', or in the environment to alter how the implicit rules work without redefining the rules themselves. You can cancel all variables used by implicit rules with the `-R' or `--no-builtin-variables' option. For example, the command used to compile a C source file actually says `$(CC) -c $(CFLAGS) $(CPPFLAGS)'. The default values of the variables used are `cc' and nothing, resulting in the command `cc -c'. By redefining `CC' to `ncc', you could cause `ncc' to be used for all C compilations performed by the implicit rule. By redefining `CFLAGS' to be `-g', you could pass the `-g' option to each compilation. _All_ implicit rules that do C compilation use `$(CC)' to get the program name for the compiler and _all_ include `$(CFLAGS)' among the arguments given to the compiler. The variables used in implicit rules fall into two classes: those that are names of programs (like `CC') and those that contain arguments for the programs (like `CFLAGS'). (The "name of a program" may also contain some command arguments, but it must start with an actual executable program name.) If a variable value contains more than one argument, separate them with spaces. The following tables describe of some of the more commonly-used predefined variables. This list is not exhaustive, and the default values shown here may not be what are selected by `make' for your environment. To see the complete list of predefined variables for your instance of GNU `make' you can run `make -p' in a directory with no makefiles. Here is a table of some of the more common variables used as names of programs in built-in rules: makefiles. `AR' Archive-maintaining program; default `ar'. `AS' Program for compiling assembly files; default `as'. `CC' Program for compiling C programs; default `cc'. `CO' Program for checking out files from RCS; default `co'. `CXX' Program for compiling C++ programs; default `g++'. `CO' Program for extracting a file from RCS; default `co'. `CPP' Program for running the C preprocessor, with results to standard output; default `$(CC) -E'. `FC' Program for compiling or preprocessing Fortran and Ratfor programs; default `f77'. `GET' Program for extracting a file from SCCS; default `get'. `LEX' Program to use to turn Lex grammars into source code; default `lex'. `YACC' Program to use to turn Yacc grammars into source code; default `yacc'. `LINT' Program to use to run lint on source code; default `lint'. `M2C' Program to use to compile Modula-2 source code; default `m2c'. `PC' Program for compiling Pascal programs; default `pc'. `MAKEINFO' Program to convert a Texinfo source file into an Info file; default `makeinfo'. `TEX' Program to make TeX DVI files from TeX source; default `tex'. `TEXI2DVI' Program to make TeX DVI files from Texinfo source; default `texi2dvi'. `WEAVE' Program to translate Web into TeX; default `weave'. `CWEAVE' Program to translate C Web into TeX; default `cweave'. `TANGLE' Program to translate Web into Pascal; default `tangle'. `CTANGLE' Program to translate C Web into C; default `ctangle'. `RM' Command to remove a file; default `rm -f'. Here is a table of variables whose values are additional arguments for the programs above. The default values for all of these is the empty string, unless otherwise noted. `ARFLAGS' Flags to give the archive-maintaining program; default `rv'. `ASFLAGS' Extra flags to give to the assembler (when explicitly invoked on a `.s' or `.S' file). `CFLAGS' Extra flags to give to the C compiler. `CXXFLAGS' Extra flags to give to the C++ compiler. `COFLAGS' Extra flags to give to the RCS `co' program. `CPPFLAGS' Extra flags to give to the C preprocessor and programs that use it (the C and Fortran compilers). `FFLAGS' Extra flags to give to the Fortran compiler. `GFLAGS' Extra flags to give to the SCCS `get' program. `LDFLAGS' Extra flags to give to compilers when they are supposed to invoke the linker, `ld'. `LFLAGS' Extra flags to give to Lex. `YFLAGS' Extra flags to give to Yacc. `PFLAGS' Extra flags to give to the Pascal compiler. `RFLAGS' Extra flags to give to the Fortran compiler for Ratfor programs. `LINTFLAGS' Extra flags to give to lint.  File: make.info, Node: Chained Rules, Next: Pattern Rules, Prev: Implicit Variables, Up: Implicit Rules 10.4 Chains of Implicit Rules ============================= Sometimes a file can be made by a sequence of implicit rules. For example, a file `N.o' could be made from `N.y' by running first Yacc and then `cc'. Such a sequence is called a "chain". If the file `N.c' exists, or is mentioned in the makefile, no special searching is required: `make' finds that the object file can be made by C compilation from `N.c'; later on, when considering how to make `N.c', the rule for running Yacc is used. Ultimately both `N.c' and `N.o' are updated. However, even if `N.c' does not exist and is not mentioned, `make' knows how to envision it as the missing link between `N.o' and `N.y'! In this case, `N.c' is called an "intermediate file". Once `make' has decided to use the intermediate file, it is entered in the data base as if it had been mentioned in the makefile, along with the implicit rule that says how to create it. Intermediate files are remade using their rules just like all other files. But intermediate files are treated differently in two ways. The first difference is what happens if the intermediate file does not exist. If an ordinary file B does not exist, and `make' considers a target that depends on B, it invariably creates B and then updates the target from B. But if B is an intermediate file, then `make' can leave well enough alone. It won't bother updating B, or the ultimate target, unless some prerequisite of B is newer than that target or there is some other reason to update that target. The second difference is that if `make' _does_ create B in order to update something else, it deletes B later on after it is no longer needed. Therefore, an intermediate file which did not exist before `make' also does not exist after `make'. `make' reports the deletion to you by printing a `rm -f' command showing which file it is deleting. Ordinarily, a file cannot be intermediate if it is mentioned in the makefile as a target or prerequisite. However, you can explicitly mark a file as intermediate by listing it as a prerequisite of the special target `.INTERMEDIATE'. This takes effect even if the file is mentioned explicitly in some other way. You can prevent automatic deletion of an intermediate file by marking it as a "secondary" file. To do this, list it as a prerequisite of the special target `.SECONDARY'. When a file is secondary, `make' will not create the file merely because it does not already exist, but `make' does not automatically delete the file. Marking a file as secondary also marks it as intermediate. You can list the target pattern of an implicit rule (such as `%.o') as a prerequisite of the special target `.PRECIOUS' to preserve intermediate files made by implicit rules whose target patterns match that file's name; see *Note Interrupts::. A chain can involve more than two implicit rules. For example, it is possible to make a file `foo' from `RCS/foo.y,v' by running RCS, Yacc and `cc'. Then both `foo.y' and `foo.c' are intermediate files that are deleted at the end. No single implicit rule can appear more than once in a chain. This means that `make' will not even consider such a ridiculous thing as making `foo' from `foo.o.o' by running the linker twice. This constraint has the added benefit of preventing any infinite loop in the search for an implicit rule chain. There are some special implicit rules to optimize certain cases that would otherwise be handled by rule chains. For example, making `foo' from `foo.c' could be handled by compiling and linking with separate chained rules, using `foo.o' as an intermediate file. But what actually happens is that a special rule for this case does the compilation and linking with a single `cc' command. The optimized rule is used in preference to the step-by-step chain because it comes earlier in the ordering of rules. This is doc/gccinstall.info, produced by makeinfo version 4.12 from /usr/local/home/bellard/cpux86/rootdisk/buildroot-2011.02/output/toolchain/gcc-4.3.5/gcc/doc/install.texi. Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, the Front-Cover texts being (a) (see below), and with the Back-Cover Texts being (b) (see below). A copy of the license is included in the section entitled "GNU Free Documentation License". (a) The FSF's Front-Cover Text is: A GNU Manual (b) The FSF's Back-Cover Text is: You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development. Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, the Front-Cover texts being (a) (see below), and with the Back-Cover Texts being (b) (see below). A copy of the license is included in the section entitled "GNU Free Documentation License". (a) The FSF's Front-Cover Text is: A GNU Manual (b) The FSF's Back-Cover Text is: You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development. INFO-DIR-SECTION Software development START-INFO-DIR-ENTRY * gccinstall: (gccinstall). Installing the GNU Compiler Collection. END-INFO-DIR-ENTRY  File: gccinstall.info, Node: Top, Up: (dir) * Menu: * Installing GCC:: This document describes the generic installation procedure for GCC as well as detailing some target specific installation instructions. * Specific:: Host/target specific installation notes for GCC. * Binaries:: Where to get pre-compiled binaries. * Old:: Old installation documentation. * GNU Free Documentation License:: How you can copy and share this manual. * Concept Index:: This index has two entries.  File: gccinstall.info, Node: Installing GCC, Next: Binaries, Up: Top 1 Installing GCC **************** The latest version of this document is always available at http://gcc.gnu.org/install/. This document describes the generic installation procedure for GCC as well as detailing some target specific installation instructions. GCC includes several components that previously were separate distributions with their own installation instructions. This document supersedes all package specific installation instructions. _Before_ starting the build/install procedure please check the *note host/target specific installation notes: Specific. We recommend you browse the entire generic installation instructions before you proceed. Lists of successful builds for released versions of GCC are available at `http://gcc.gnu.org/buildstat.html'. These lists are updated as new information becomes available. The installation procedure itself is broken into five steps. * Menu: * Prerequisites:: * Downloading the source:: * Configuration:: * Building:: * Testing:: (optional) * Final install:: Please note that GCC does not support `make uninstall' and probably won't do so in the near future as this would open a can of worms. Instead, we suggest that you install GCC into a directory of its own and simply remove that directory when you do not need that specific version of GCC any longer, and, if shared libraries are installed there as well, no more binaries exist that use them.  File: gccinstall.info, Node: Prerequisites, Next: Downloading the source, Up: Installing GCC 2 Prerequisites *************** GCC requires that various tools and packages be available for use in the build procedure. Modifying GCC sources requires additional tools described below. Tools/packages necessary for building GCC ========================================= ISO C90 compiler Necessary to bootstrap GCC, although versions of GCC prior to 3.4 also allow bootstrapping with a traditional (K&R) C compiler. To build all languages in a cross-compiler or other configuration where 3-stage bootstrap is not performed, you need to start with an existing GCC binary (version 2.95 or later) because source code for language frontends other than C might use GCC extensions. GNAT In order to build the Ada compiler (GNAT) you must already have GNAT installed because portions of the Ada frontend are written in Ada (with GNAT extensions.) Refer to the Ada installation instructions for more specific information. A "working" POSIX compatible shell, or GNU bash Necessary when running `configure' because some `/bin/sh' shells have bugs and may crash when configuring the target libraries. In other cases, `/bin/sh' or `ksh' have disastrous corner-case performance problems. This can cause target `configure' runs to literally take days to complete in some cases. So on some platforms `/bin/ksh' is sufficient, on others it isn't. See the host/target specific instructions for your platform, or use `bash' to be sure. Then set `CONFIG_SHELL' in your environment to your "good" shell prior to running `configure'/`make'. `zsh' is not a fully compliant POSIX shell and will not work when configuring GCC. A POSIX or SVR4 awk Necessary for creating some of the generated source files for GCC. If in doubt, use a recent GNU awk version, as some of the older ones are broken. GNU awk version 3.1.5 is known to work. GNU binutils Necessary in some circumstances, optional in others. See the host/target specific instructions for your platform for the exact requirements. gzip version 1.2.4 (or later) or bzip2 version 1.0.2 (or later) Necessary to uncompress GCC `tar' files when source code is obtained via FTP mirror sites. GNU make version 3.79.1 (or later) You must have GNU make installed to build GCC. GNU tar version 1.14 (or later) Necessary (only on some platforms) to untar the source code. Many systems' `tar' programs will also work, only try GNU `tar' if you have problems. GNU Multiple Precision Library (GMP) version 4.1 (or later) Necessary to build GCC. If you do not have it installed in your library search path, you will have to configure with the `--with-gmp' configure option. See also `--with-gmp-lib' and `--with-gmp-include'. MPFR Library version 2.3.0 (or later) Necessary to build GCC. It can be downloaded from `http://www.mpfr.org/'. The version of MPFR that is bundled with GMP 4.1.x contains numerous bugs. Although GCC may appear to function with the buggy versions of MPFR, there are a few bugs that will not be fixed when using this version. It is strongly recommended to upgrade to the recommended version of MPFR. The `--with-mpfr' configure option should be used if your MPFR Library is not installed in your default library search path. See also `--with-mpfr-lib' and `--with-mpfr-include'. `jar', or InfoZIP (`zip' and `unzip') Necessary to build libgcj, the GCJ runtime. Tools/packages necessary for modifying GCC ========================================== autoconf version 2.59 GNU m4 version 1.4 (or later) Necessary when modifying `configure.ac', `aclocal.m4', etc. to regenerate `configure' and `config.in' files. automake version 1.9.6 Necessary when modifying a `Makefile.am' file to regenerate its associated `Makefile.in'. Much of GCC does not use automake, so directly edit the `Makefile.in' file. Specifically this applies to the `gcc', `intl', `libcpp', `libiberty', `libobjc' directories as well as any of their subdirectories. For directories that use automake, GCC requires the latest release in the 1.9.x series, which is currently 1.9.6. When regenerating a directory to a newer version, please update all the directories using an older 1.9.x to the latest released version. gettext version 0.14.5 (or later) Needed to regenerate `gcc.pot'. gperf version 2.7.2 (or later) Necessary when modifying `gperf' input files, e.g. `gcc/cp/cfns.gperf' to regenerate its associated header file, e.g. `gcc/cp/cfns.h'. DejaGnu 1.4.4 Expect Tcl Necessary to run the GCC testsuite; see the section on testing for details. autogen version 5.5.4 (or later) and guile version 1.4.1 (or later) Necessary to regenerate `fixinc/fixincl.x' from `fixinc/inclhack.def' and `fixinc/*.tpl'. Necessary to run `make check' for `fixinc'. Necessary to regenerate the top level `Makefile.in' file from `Makefile.tpl' and `Makefile.def'. GNU Bison version 1.28 (or later) Necessary when modifying `*.y' files. Necessary to build the `treelang' front end (which is not enabled by default) from a checkout of the SVN repository; the generated files are not in the repository. They are included in releases. Berkeley `yacc' (`byacc') has been reported to work as well. Flex version 2.5.4 (or later) Necessary when modifying `*.l' files. Necessary to build GCC during development because the generated output files are not included in the SVN repository. They are included in releases. Texinfo version 4.4 (or later) Necessary for running `makeinfo' when modifying `*.texi' files to test your changes. Necessary for running `make dvi' or `make pdf' to create printable documentation in DVI or PDF format. Texinfo version 4.8 or later is required for `make pdf'. Necessary to build GCC documentation during development because the generated output files are not included in the SVN repository. They are included in releases. TeX (any working version) Necessary for running `texi2dvi' and `texi2pdf', which are used when running `make dvi' or `make pdf' to create DVI or PDF files, respectively. SVN (any version) SSH (any version) Necessary to access the SVN repository. Public releases and weekly snapshots of the development sources are also available via FTP. Perl version 5.6.1 (or later) Necessary when regenerating `Makefile' dependencies in libiberty. Necessary when regenerating `libiberty/functions.texi'. Necessary when generating manpages from Texinfo manuals. Necessary when targetting Darwin, building libstdc++, and not using `--disable-symvers'. Used by various scripts to generate some files included in SVN (mainly Unicode-related and rarely changing) from source tables. GNU diffutils version 2.7 (or later) Useful when submitting patches for the GCC source code. patch version 2.5.4 (or later) Necessary when applying patches, created with `diff', to one's own sources. ecj1 gjavah If you wish to modify `.java' files in libjava, you will need to configure with `--enable-java-maintainer-mode', and you will need to have executables named `ecj1' and `gjavah' in your path. The `ecj1' executable should run the Eclipse Java compiler via the GCC-specific entry point. You can download a suitable jar from `ftp://sourceware.org/pub/java/', or by running the script `contrib/download_ecj'.  File: gccinstall.info, Node: Downloading the source, Next: Configuration, Prev: Prerequisites, Up: Installing GCC 3 Downloading GCC ***************** GCC is distributed via SVN and FTP tarballs compressed with `gzip' or `bzip2'. It is possible to download a full distribution or specific components. Please refer to the releases web page for information op™q™r™s™t™u™v™w™x™y™z™{™|™}™~™™€™™‚™ƒ™„™…™†™‡™ˆ™‰™Š™‹™Œ™™Ž™™™‘™’™“™”™•™–™—™˜™™™š™›™œ™™ž™Ÿ™ ™¡™¢™£™¤™¥™¦™§™¨™©™ª™«™¬™­™®™¯™°™±™²™³™´™µ™¶™·™¸™¹™º™»™¼™½™¾™¿™À™Á™Â™Ã™Ä™Å™Æ™Ç™È™É™Ê™Ë™Ì™Í™Î™Ï™Ð™Ñ™Ò™Ó™Ô™Õ™Ö™×™Ø™Ù™Ú™Û™Ü™Ý™Þ™ß™à™á™â™ã™ä™å™æ™ç™è™é™ê™ë™ì™í™î™ï™ð™ñ™ò™ó™ô™õ™ö™÷™ø™ù™ú™û™ü™ý™þ™ÿ™ššššššššš š š š š šššššššššššššn how to obtain GCC. The full distribution includes the C, C++, Objective-C, Fortran, Java, and Ada (in the case of GCC 3.1 and later) compilers. The full distribution also includes runtime libraries for C++, Objective-C, Fortran, and Java. In GCC 3.0 and later versions, the GNU compiler testsuites are also included in the full distribution. If you choose to download specific components, you must download the core GCC distribution plus any language specific distributions you wish to use. The core distribution includes the C language front end as well as the shared components. Each language has a tarball which includes the language front end as well as the language runtime (when appropriate). Unpack the core distribution as well as any language specific distributions in the same directory. If you also intend to build binutils (either to upgrade an existing installation or for use in place of the corresponding tools of your OS), unpack the binutils distribution either in the same directory or a separate one. In the latter case, add symbolic links to any components of the binutils you intend to build alongside the compiler (`bfd', `binutils', `gas', `gprof', `ld', `opcodes', ...) to the directory containing the GCC sources.  File: gccinstall.info, Node: Configuration, Next: Building, Prev: Downloading the source, Up: Installing GCC 4 Installing GCC: Configuration ******************************* Like most GNU software, GCC must be configured before it can be built. This document describes the recommended configuration procedure for both native and cross targets. We use SRCDIR to refer to the toplevel source directory for GCC; we use OBJDIR to refer to the toplevel build/object directory. If you obtained the sources via SVN, SRCDIR must refer to the top `gcc' directory, the one where the `MAINTAINERS' can be found, and not its `gcc' subdirectory, otherwise the build will fail. If either SRCDIR or OBJDIR is located on an automounted NFS file system, the shell's built-in `pwd' command will return temporary pathnames. Using these can lead to various sorts of build problems. To avoid this issue, set the `PWDCMD' environment variable to an automounter-aware `pwd' command, e.g., `pawd' or `amq -w', during the configuration and build phases. First, we *highly* recommend that GCC be built into a separate directory than the sources which does *not* reside within the source tree. This is how we generally build GCC; building where SRCDIR == OBJDIR should still work, but doesn't get extensive testing; building where OBJDIR is a subdirectory of SRCDIR is unsupported. If you have previously built GCC in the same directory for a different target machine, do `make distclean' to delete all files that might be invalid. One of the files this deletes is `Makefile'; if `make distclean' complains that `Makefile' does not exist or issues a message like "don't know how to make distclean" it probably means that the directory is already suitably clean. However, with the recommended method of building in a separate OBJDIR, you should simply use a different OBJDIR for each target. Second, when configuring a native system, either `cc' or `gcc' must be in your path or you must set `CC' in your environment before running configure. Otherwise the configuration scripts may fail. To configure GCC: % mkdir OBJDIR % cd OBJDIR % SRCDIR/configure [OPTIONS] [TARGET] Distributor options =================== If you will be distributing binary versions of GCC, with modifications to the source code, you should use the options described in this section to make clear that your version contains modifications. `--with-pkgversion=VERSION' Specify a string that identifies your package. You may wish to include a build number or build date. This version string will be included in the output of `gcc --version'. This suffix does not replace the default version string, only the `GCC' part. The default value is `GCC'. `--with-bugurl=URL' Specify the URL that users should visit if they wish to report a bug. You are of course welcome to forward bugs reported to you to the FSF, if you determine that they are not bugs in your modifications. The default value refers to the FSF's GCC bug tracker. Target specification ==================== * GCC has code to correctly determine the correct value for TARGET for nearly all native systems. Therefore, we highly recommend you not provide a configure target when configuring a native compiler. * TARGET must be specified as `--target=TARGET' when configuring a cross compiler; examples of valid targets would be m68k-coff, sh-elf, etc. * Specifying just TARGET instead of `--target=TARGET' implies that the host defaults to TARGET. Options specification ===================== Use OPTIONS to override several configure time options for GCC. A list of supported OPTIONS follows; `configure --help' may list other options, but those not listed below may not work and should not normally be used. Note that each `--enable' option has a corresponding `--disable' option and that each `--with' option has a corresponding `--without' option. `--prefix=DIRNAME' Specify the toplevel installation directory. This is the recommended way to install the tools into a directory other than the default. The toplevel installation directory defaults to `/usr/local'. We *highly* recommend against DIRNAME being the same or a subdirectory of OBJDIR or vice versa. If specifying a directory beneath a user's home directory tree, some shells will not expand DIRNAME correctly if it contains the `~' metacharacter; use `$HOME' instead. The following standard `autoconf' options are supported. Normally you should not need to use these options. `--exec-prefix=DIRNAME' Specify the toplevel installation directory for architecture-dependent files. The default is `PREFIX'. `--bindir=DIRNAME' Specify the installation directory for the executables called by users (such as `gcc' and `g++'). The default is `EXEC-PREFIX/bin'. `--libdir=DIRNAME' Specify the installation directory for object code libraries and internal data files of GCC. The default is `EXEC-PREFIX/lib'. `--libexecdir=DIRNAME' Specify the installation directory for internal executables of GCC. The default is `EXEC-PREFIX/libexec'. `--with-slibdir=DIRNAME' Specify the installation directory for the shared libgcc library. The default is `LIBDIR'. `--infodir=DIRNAME' Specify the installation directory for documentation in info format. The default is `PREFIX/info'. `--datadir=DIRNAME' Specify the installation directory for some architecture-independent data files referenced by GCC. The default is `PREFIX/share'. `--mandir=DIRNAME' Specify the installation directory for manual pages. The default is `PREFIX/man'. (Note that the manual pages are only extracts from the full GCC manuals, which are provided in Texinfo format. The manpages are derived by an automatic conversion process from parts of the full manual.) `--with-gxx-include-dir=DIRNAME' Specify the installation directory for G++ header files. The default is `PREFIX/include/c++/VERSION'. `--program-prefix=PREFIX' GCC supports some transformations of the names of its programs when installing them. This option prepends PREFIX to the names of programs to install in BINDIR (see above). For example, specifying `--program-prefix=foo-' would result in `gcc' being installed as `/usr/local/bin/foo-gcc'. `--program-suffix=SUFFIX' Appends SUFFIX to the names of programs to install in BINDIR (see above). For example, specifying `--program-suffix=-3.1' would result in `gcc' being installed as `/usr/local/bin/gcc-3.1'. `--program-transform-name=PATTERN' Applies the `sed' script PATTERN to be applied to the names of programs to install in BINDIR (see above). PATTERN has to consist of one or more basic `sed' editing commands, separated by semicolons. For example, if you want the `gcc' program name to be transformed to the installed program `/usr/local/bin/myowngcc' and the `g++' program name to be transformed to `/usr/local/bin/gspecial++' without changing other program names, you could use the pattern `--program-transform-name='s/^gcc$/myowngcc/; s/^g++$/gspecial++/'' to achieve this effect. All three options can be combined and used together, resulting in more complex conversion patterns. As a basic rule, PREFIX (and SUFFIX) are prepended (appended) before further transformations can happen with a special transformation script PATTERN. As currently implemented, this option only takes effect for native builds; cross compiler binaries' names are not transformed even when a transformation is explicitly asked for by one of these options. For native builds, some of the installed programs are also installed with the target alias in front of their name, as in `i686-pc-linux-gnu-gcc'. All of the above transformations happen before the target alias is prepended to the name--so, specifying `--program-prefix=foo-' and `program-suffix=-3.1', the resulting binary would be installed as `/usr/local/bin/i686-pc-linux-gnu-foo-gcc-3.1'. As a last shortcoming, none of the installed Ada programs are transformed yet, which will be fixed in some time. `--with-local-prefix=DIRNAME' Specify the installation directory for local include files. The default is `/usr/local'. Specify this option if you want the compiler to search directory `DIRNAME/include' for locally installed header files _instead_ of `/usr/local/include'. You should specify `--with-local-prefix' *only* if your site has a different convention (not `/usr/local') for where to put site-specific files. The default value for `--with-local-prefix' is `/usr/local' regardless of the value of `--prefix'. Specifying `--prefix' has no effect on which directory GCC searches for local header files. This may seem counterintuitive, but actually it is logical. The purpose of `--prefix' is to specify where to _install GCC_. The local header files in `/usr/local/include'--if you put any in that directory--are not part of GCC. They are part of other programs--perhaps many others. (GCC installs its own header files in another directory which is based on the `--prefix' value.) Both the local-prefix include directory and the GCC-prefix include directory are part of GCC's "system include" directories. Although these two directories are not fixed, they need to be searched in the proper order for the correct processing of the include_next directive. The local-prefix include directory is searched before the GCC-prefix include directory. Another characteristic of system include directories is that pedantic warnings are turned off for headers in these directories. Some autoconf macros add `-I DIRECTORY' options to the compiler command line, to ensure that directories containing installed packages' headers are searched. When DIRECTORY is one of GCC's system include directories, GCC will ignore the option so that system directories continue to be processed in the correct order. This may result in a search order different from what was specified but the directory will still be searched. GCC automatically searches for ordinary libraries using `GCC_EXEC_PREFIX'. Thus, when the same installation prefix is used for both GCC and packages, GCC will automatically search for both headers and libraries. This provides a configuration that is easy to use. GCC behaves in a manner similar to that when it is installed as a system compiler in `/usr'. Sites that need to install multiple versions of GCC may not want to use the above simple configuration. It is possible to use the `--program-prefix', `--program-suffix' and `--program-transform-name' options to install multiple versions into a single directory, but it may be simpler to use different prefixes and the `--with-local-prefix' option to specify the location of the site-specific files for each version. It will then be necessary for users to specify explicitly the location of local site libraries (e.g., with `LIBRARY_PATH'). The same value can be used for both `--with-local-prefix' and `--prefix' provided it is not `/usr'. This can be used to avoid the default search of `/usr/local/include'. *Do not* specify `/usr' as the `--with-local-prefix'! The directory you use for `--with-local-prefix' *must not* contain any of the system's standard header files. If it did contain them, certain programs would be miscompiled (including GNU Emacs, on certain targets), because this would override and nullify the header file corrections made by the `fixincludes' script. Indications are that people who use this option use it based on mistaken ideas of what it is for. People use it as if it specified where to install part of GCC. Perhaps they make this assumption because installing GCC creates the directory. `--enable-shared[=PACKAGE[,...]]' Build shared versions of libraries, if shared libraries are supported on the target platform. Unlike GCC 2.95.x and earlier, shared libraries are enabled by default on all platforms that support shared libraries. If a list of packages is given as an argument, build shared libraries only for the listed packages. For other packages, only static libraries will be built. Package names currently recognized in the GCC tree are `libgcc' (also known as `gcc'), `libstdc++' (not `libstdc++-v3'), `libffi', `zlib', `boehm-gc', `ada', `libada', `libjava' and `libobjc'. Note `libiberty' does not support shared libraries at all. Use `--disable-shared' to build only static libraries. Note that `--disable-shared' does not accept a list of package names as argument, only `--enable-shared' does. `--with-gnu-as' Specify that the compiler should assume that the assembler it finds is the GNU assembler. However, this does not modify the rules to find an assembler and will result in confusion if the assembler found is not actually the GNU assembler. (Confusion may also result if the compiler finds the GNU assembler but has not been configured with `--with-gnu-as'.) If you have more than one assembler installed on your system, you may want to use this option in connection with `--with-as=PATHNAME' or `--with-build-time-tools=PATHNAME'. The following systems are the only ones where it makes a difference whether you use the GNU assembler. On any other system, `--with-gnu-as' has no effect. * `hppa1.0-ANY-ANY' * `hppa1.1-ANY-ANY' * `i386-ANY-sysv' * `m68k-bull-sysv' * `m68k-hp-hpux' * `m68000-hp-hpux' * `m68000-att-sysv' * `sparc-sun-solaris2.ANY' * `sparc64-ANY-solaris2.ANY' On the systems listed above (except for the HP-PA, the SPARC, for ISC on the 386, if you use the GNU assembler, you should also use the GNU linker (and specify `--with-gnu-ld'). `--with-as=PATHNAME' Specify that the compiler should use the assembler pointed to by PATHNAME, rather than the one found by the standard rules to find an assembler, which are: * Unless GCC is being built with a cross compiler, check the `LIBEXEC/gcc/TARGET/VERSION' directory. LIBEXEC defaults to `EXEC-PREFIX/libexec'; EXEC-PREFIX defaults to PREFIX, which defaults to `/usr/local' unless overridden by the