diff options
Diffstat (limited to 'gnu/usr.bin/binutils')
| -rw-r--r-- | gnu/usr.bin/binutils/etc/configure.texi | 2644 | ||||
| -rw-r--r-- | gnu/usr.bin/binutils/gas/config/te-obsd.h | 24 | ||||
| -rw-r--r-- | gnu/usr.bin/binutils/ld/emulparams/elf64btsmip_obsd.sh | 6 | ||||
| -rw-r--r-- | gnu/usr.bin/binutils/mpw-README | 376 | ||||
| -rw-r--r-- | gnu/usr.bin/binutils/mpw-build.in | 204 | ||||
| -rw-r--r-- | gnu/usr.bin/binutils/mpw-config.in | 113 | ||||
| -rw-r--r-- | gnu/usr.bin/binutils/mpw-configure | 448 | ||||
| -rw-r--r-- | gnu/usr.bin/binutils/mpw-install | 122 |
8 files changed, 2674 insertions, 1263 deletions
diff --git a/gnu/usr.bin/binutils/etc/configure.texi b/gnu/usr.bin/binutils/etc/configure.texi new file mode 100644 index 00000000000..d69dc414d0f --- /dev/null +++ b/gnu/usr.bin/binutils/etc/configure.texi @@ -0,0 +1,2644 @@ +\input texinfo +@c %**start of header +@setfilename configure.info +@settitle The GNU configure and build system +@setchapternewpage off +@c %**end of header + +@dircategory GNU admin +@direntry +* configure: (configure). The GNU configure and build system +@end direntry + +@ifinfo +This file documents the GNU configure and build system. + +Copyright (C) 1998 Cygnus Solutions. + +Permission is granted to make and distribute verbatim copies of +this manual provided the copyright notice and this permission notice +are preserved on all copies. + +@ignore +Permission is granted to process this file through TeX and print the +results, provided the printed document carries copying permission +notice identical to this one except for the removal of this paragraph + + +@end ignore +Permission is granted to copy and distribute modified versions of this +manual under the conditions for verbatim copying, provided that the entire +resulting derived work is distributed under the terms of a permission +notice identical to this one. + +Permission is granted to copy and distribute translations of this manual +into another language, under the above conditions for modified versions, +except that this permission notice may be stated in a translation approved +by the Foundation. +@end ifinfo + +@titlepage +@title The GNU configure and build system +@author Ian Lance Taylor + +@page +@vskip 0pt plus 1filll +Copyright @copyright{} 1998 Cygnus Solutions + +Permission is granted to make and distribute verbatim copies of +this manual provided the copyright notice and this permission notice +are preserved on all copies. + +Permission is granted to copy and distribute modified versions of this +manual under the conditions for verbatim copying, provided that the entire +resulting derived work is distributed under the terms of a permission +notice identical to this one. + +Permission is granted to copy and distribute translations of this manual +into another language, under the above conditions for modified versions, +except that this permission notice may be stated in a translation +approved by the Free Software Foundation. +@end titlepage + +@ifinfo +@node Top +@top GNU configure and build system + +The GNU configure and build system. + +@menu +* Introduction:: Introduction. +* Getting Started:: Getting Started. +* Files:: Files. +* Configuration Names:: Configuration Names. +* Cross Compilation Tools:: Cross Compilation Tools. +* Canadian Cross:: Canadian Cross. +* Cygnus Configure:: Cygnus Configure. +* Multilibs:: Multilibs. +* FAQ:: Frequently Asked Questions. +* Index:: Index. +@end menu + +@end ifinfo + +@node Introduction +@chapter Introduction + +This document describes the GNU configure and build systems. It +describes how autoconf, automake, libtool, and make fit together. It +also includes a discussion of the older Cygnus configure system. + +This document does not describe in detail how to use each of the tools; +see the respective manuals for that. Instead, it describes which files +the developer must write, which files are machine generated and how they +are generated, and where certain common problems should be addressed. + +@ifnothtml +This document draws on several sources, including the autoconf manual by +David MacKenzie (@pxref{Top, , autoconf overview, autoconf, Autoconf}), +the automake manual by David MacKenzie and Tom Tromey (@pxref{Top, , +automake overview, automake, GNU Automake}), the libtool manual by +Gordon Matzigkeit (@pxref{Top, , libtool overview, libtool, GNU +libtool}), and the Cygnus configure manual by K. Richard Pixley. +@end ifnothtml +@ifhtml +This document draws on several sources, including +@uref{http://www.delorie.com/gnu/docs/autoconf/autoconf_toc.html, the +autoconf manual} by David MacKenzie, +@uref{http://www.delorie.com/gnu/docs/automake/automake_toc.html, the +automake manual} by David MacKenzie and Tom Tromey, +@uref{http://www.delorie.com/gnu/docs/libtool/libtool_toc.html, the +libtool manual} by Gordon Matzigkeit, and the Cygnus configure manual by +K. Richard Pixley. +@end ifhtml + +@menu +* Goals:: Goals. +* Tools:: The tools. +* History:: History. +* Building:: Building. +@end menu + +@node Goals +@section Goals +@cindex goals + +The GNU configure and build system has two main goals. + +The first is to simplify the development of portable programs. The +system permits the developer to concentrate on writing the program, +simplifying many details of portability across Unix and even Windows +systems, and permitting the developer to describe how to build the +program using simple rules rather than complex Makefiles. + +The second is to simplify the building of programs distributed as source +code. All programs are built using a simple, standardized, two step +process. The program builder need not install any special tools in +order to build the program. + +@node Tools +@section Tools + +The GNU configure and build system is comprised of several different +tools. Program developers must build and install all of these tools. + +People who just want to build programs from distributed sources normally +do not need any special tools beyond a Unix shell, a make program, and a +C compiler. + +@table @asis +@item autoconf +provides a general portability framework, based on testing the features +of the host system at build time. +@item automake +a system for describing how to build a program, permitting the developer +to write a simplified @file{Makefile}. +@item libtool +a standardized approach to building shared libraries. +@item gettext +provides a framework for translation of text messages into other +languages; not really discussed in this document. +@item m4 +autoconf requires the GNU version of m4; the standard Unix m4 does not +suffice. +@item perl +automake requires perl. +@end table + +@node History +@section History +@cindex history + +This is a very brief and probably inaccurate history. + +As the number of Unix variants increased during the 1980s, it became +harder to write programs which could run on all variants. While it was +often possible to use @code{#ifdef} to identify particular systems, +developers frequently did not have access to every system, and the +characteristics of some systems changed from version to version. + +By 1992, at least three different approaches had been developed: +@itemize @bullet +@item +The Metaconfig program, by Larry Wall, Harlan Stenn, and Raphael +Manfredi. +@item +The Cygnus configure script, by K. Richard Pixley, and the gcc configure +script, by Richard Stallman. These use essentially the same approach, +and the developers communicated regularly. +@item +The autoconf program, by David MacKenzie. +@end itemize + +The Metaconfig program is still used for Perl and a few other programs. +It is part of the Dist package. I do not know if it is being developed. + +In 1994, David MacKenzie and others modified autoconf to incorporate all +the features of Cygnus configure. Since then, there has been a slow but +steady conversion of GNU programs from Cygnus configure to autoconf. gcc +has been converted, eliminating the gcc configure script. + +GNU autoconf was regularly maintained until late 1996. As of this +writing in June, 1998, it has no public maintainer. + +Most programs are built using the make program, which requires the +developer to write Makefiles describing how to build the programs. +Since most programs are built in pretty much the same way, this led to a +lot of duplication. + +The X Window system is built using the imake tool, which uses a database +of rules to eliminate the duplication. However, building a tool which +was developed using imake requires that the builder have imake +installed, violating one of the goals of the GNU system. + +The new BSD make provides a standard library of Makefile fragments, +which permits developers to write very simple Makefiles. However, this +requires that the builder install the new BSD make program. + +In 1994, David MacKenzie wrote the first version of automake, which +permitted writing a simple build description which was converted into a +Makefile which could be used by the standard make program. In 1995, Tom +Tromey completely rewrote automake in Perl, and he continues to enhance +it. + +Various free packages built libraries, and by around 1995 several +included support to build shared libraries on various platforms. +However, there was no consistent approach. In early 1996, Gordon +Matzigkeit began working on libtool, which provided a standardized +approach to building shared libraries. This was integrated into +automake from the start. + +The development of automake and libtool was driven by the GNITS project, +a group of GNU maintainers who designed standardized tools to help meet +the GNU coding standards. + +@node Building +@section Building + +Most readers of this document should already know how to build a tool by +running @samp{configure} and @samp{make}. This section may serve as a +quick introduction or reminder. + +Building a tool is normally as simple as running @samp{configure} +followed by @samp{make}. You should normally run @samp{configure} from +an empty directory, using some path to refer to the @samp{configure} +script in the source directory. The directory in which you run +@samp{configure} is called the @dfn{object directory}. + +In order to use a object directory which is different from the source +directory, you must be using the GNU version of @samp{make}, which has +the required @samp{VPATH} support. Despite this restriction, using a +different object directory is highly recommended: +@itemize @bullet +@item +It keeps the files generated during the build from cluttering up your +sources. +@item +It permits you to remove the built files by simply removing the entire +build directory. +@item +It permits you to build from the same sources with several sets of +configure options simultaneously. +@end itemize + +If you don't have GNU @samp{make}, you will have to run @samp{configure} +in the source directory. All GNU packages should support this; in +particular, GNU packages should not assume the presence of GNU +@samp{make}. + +After running @samp{configure}, you can build the tools by running +@samp{make}. + +To install the tools, run @samp{make install}. Installing the tools +will copy the programs and any required support files to the +@dfn{installation directory}. The location of the installation +directory is controlled by @samp{configure} options, as described below. + +In the Cygnus tree at present, the info files are built and installed as +a separate step. To build them, run @samp{make info}. To install them, +run @samp{make install-info}. + +All @samp{configure} scripts support a wide variety of options. The +most interesting ones are @samp{--with} and @samp{--enable} options +which are generally specific to particular tools. You can usually use +the @samp{--help} option to get a list of interesting options for a +particular configure script. + +The only generic options you are likely to use are the @samp{--prefix} +and @samp{--exec-prefix} options. These options are used to specify the +installation directory. + +The directory named by the @samp{--prefix} option will hold machine +independent files such as info files. + +The directory named by the @samp{--exec-prefix} option, which is +normally a subdirectory of the @samp{--prefix} directory, will hold +machine dependent files such as executables. + +The default for @samp{--prefix} is @file{/usr/local}. The default for +@samp{--exec-prefix} is the value used for @samp{--prefix}. + +The convention used in Cygnus releases is to use a @samp{--prefix} +option of @file{/usr/cygnus/@var{release}}, where @var{release} is the +name of the release, and to use a @samp{--exec-prefix} option of +@file{/usr/cygnus/@var{release}/H-@var{host}}, where @var{host} is the +configuration name of the host system (@pxref{Configuration Names}). + +Do not use either the source or the object directory as the installation +directory. That will just lead to confusion. + +@node Getting Started +@chapter Getting Started + +To start using the GNU configure and build system with your software +package, you must write three files, and you must run some tools to +manually generate additional files. + +@menu +* Write configure.in:: Write configure.in. +* Write Makefile.am:: Write Makefile.am. +* Write acconfig.h:: Write acconfig.h. +* Generate files:: Generate files. +* Getting Started Example:: Example. +@end menu + +@node Write configure.in +@section Write configure.in +@cindex @file{configure.in}, writing + +You must first write the file @file{configure.in}. This is an autoconf +input file, and the autoconf manual describes in detail what this file +should look like. + +You will write tests in your @file{configure.in} file to check for +conditions that may change from one system to another, such as the +presence of particular header files or functions. + +For example, not all systems support the @samp{gettimeofday} function. +If you want to use the @samp{gettimeofday} function when it is +available, and to use some other function when it is not, you would +check for this by putting @samp{AC_CHECK_FUNCS(gettimeofday)} in +@file{configure.in}. + +When the configure script is run at build time, this will arrange to +define the preprocessor macro @samp{HAVE_GETTIMEOFDAY} to the value 1 if +the @samp{gettimeofday} function is available, and to not define the +macro at all if the function is not available. Your code can then use +@samp{#ifdef} to test whether it is safe to call @samp{gettimeofday}. + +If you have an existing body of code, the @samp{autoscan} program may +help identify potential portability problems, and hence configure tests +that you will want to use. +@ifnothtml +@xref{Invoking autoscan, , , autoconf, the autoconf manual}. +@end ifnothtml +@ifhtml +See @uref{http://www.delorie.com/gnu/docs/autoconf/autoconf_4.html, the +autoscan documentation}. +@end ifhtml + +Another handy tool for an existing body of code is @samp{ifnames}. This +will show you all the preprocessor conditionals that the code already +uses. +@ifnothtml +@xref{Invoking ifnames, , , autoconf, the autoconf manual}. +@end ifnothtml +@ifhtml +See @uref{http://www.delorie.com/gnu/docs/autoconf/autoconf_5.html, the +ifnames documentation}. +@end ifhtml + +Besides the portability tests which are specific to your particular +package, every @file{configure.in} file should contain the following +macros. + +@table @samp +@item AC_INIT +@cindex @samp{AC_INIT} +This macro takes a single argument, which is the name of a file in your +package. For example, @samp{AC_INIT(foo.c)}. + +@item AC_PREREQ(@var{VERSION}) +@cindex @samp{AC_PREREQ} +This macro is optional. It may be used to indicate the version of +@samp{autoconf} that you are using. This will prevent users from +running an earlier version of @samp{autoconf} and perhaps getting an +invalid @file{configure} script. For example, @samp{AC_PREREQ(2.12)}. + +@item AM_INIT_AUTOMAKE +@cindex @samp{AM_INIT_AUTOMAKE} +This macro takes two arguments: the name of the package, and a version +number. For example, @samp{AM_INIT_AUTOMAKE(foo, 1.0)}. (This macro is +not needed if you are not using automake). + +@item AM_CONFIG_HEADER +@cindex @samp{AM_CONFIG_HEADER} +This macro names the header file which will hold the preprocessor macro +definitions at run time. Normally this should be @file{config.h}. Your +sources would then use @samp{#include "config.h"} to include it. + +This macro may optionally name the input file for that header file; by +default, this is @file{config.h.in}, but that file name works poorly on +DOS filesystems. Therefore, it is often better to name it explicitly as +@file{config.in}. + +This is what you should normally put in @file{configure.in}: +@example +AM_CONFIG_HEADER(config.h:config.in) +@end example + +@cindex @samp{AC_CONFIG_HEADER} +(If you are not using automake, use @samp{AC_CONFIG_HEADER} rather than +@samp{AM_CONFIG_HEADER}). + +@item AM_MAINTAINER_MODE +@cindex @samp{AM_MAINTAINER_MODE} +This macro always appears in Cygnus configure scripts. Other programs +may or may not use it. + +If this macro is used, the @samp{--enable-maintainer-mode} option is +required to enable automatic rebuilding of generated files used by the +configure system. This of course requires that developers be aware of, +and use, that option. + +If this macro is not used, then the generated files will always be +rebuilt automatically. This will cause problems if the wrong versions +of autoconf, automake, or others are in the builder's @samp{PATH}. + +(If you are not using automake, you do not need to use this macro). + +@item AC_EXEEXT +@cindex @samp{AC_EXEEXT} +@cindex @samp{AM_EXEEXT} +Either this macro or @samp{AM_EXEEXT} always appears in Cygnus configure +files. Other programs may or may not use one of them. + +This macro looks for the executable suffix used on the host system. On +Unix systems, this is the empty string. On Windows systems, this is +@samp{.exe}. This macro directs automake to use the executable suffix +as appropriate when creating programs. This macro does not take any +arguments. + +The @samp{AC_EXEEXT} form is new, and is part of a Cygnus patch to +autoconf to support compiling with Visual C++. Older programs use +@samp{AM_EXEEXT} instead. + +(Programs which do not use automake use neither @samp{AC_EXEEXT} nor +@samp{AM_EXEEXT}). + +@item AC_PROG_CC +@cindex @samp{AC_PROG_CC} +If you are writing C code, you will normally want to use this macro. It +locates the C compiler to use. It does not take any arguments. + +However, if this @file{configure.in} file is for a library which is to +be compiled by a cross compiler which may not fully work, then you will +not want to use @samp{AC_PROG_CC}. Instead, you will want to use a +variant which does not call the macro @samp{AC_PROG_CC_WORKS}. Examples +can be found in various @file{configure.in} files for libraries that are +compiled with cross compilers, such as libiberty or libgloss. This is +essentially a bug in autoconf, and there will probably be a better +workaround at some point. + +@item AC_PROG_CXX +@cindex @samp{AC_PROG_CXX} +If you are writing C++ code, you will want to use this macro. It +locates the C++ compiler to use. It does not take any arguments. The +same cross compiler comments apply as for @samp{AC_PROG_CC}. + +@item AM_PROG_LIBTOOL +@cindex @samp{AM_PROG_LIBTOOL} +If you want to build libraries, and you want to permit them to be +shared, or you want to link against libraries which were built using +libtool, then you will need this macro. This macro is required in order +to use libtool. + +@cindex @samp{AM_DISABLE_SHARED} +By default, this will cause all libraries to be built as shared +libraries. To prevent this--to change the default--use +@samp{AM_DISABLE_SHARED} before @samp{AM_PROG_LIBTOOL}. The configure +options @samp{--enable-shared} and @samp{--disable-shared} may be used +to override the default at build time. + +@item AC_DEFINE(_GNU_SOURCE) +@cindex @samp{_GNU_SOURCE} +GNU packages should normally include this line before any other feature +tests. This defines the macro @samp{_GNU_SOURCE} when compiling, which +directs the libc header files to provide the standard GNU system +interfaces including all GNU extensions. If this macro is not defined, +certain GNU extensions may not be available. + +@item AC_OUTPUT +@cindex @samp{AC_OUTPUT} +This macro takes a list of file names which the configure process should +produce. This is normally a list of one or more @file{Makefile} files +in different directories. If your package lives entirely in a single +directory, you would use simply @samp{AC_OUTPUT(Makefile)}. If you also +have, for example, a @file{lib} subdirectory, you would use +@samp{AC_OUTPUT(Makefile lib/Makefile)}. +@end table + +If you want to use locally defined macros in your @file{configure.in} +file, then you will need to write a @file{acinclude.m4} file which +defines them (if not using automake, this file is called +@file{aclocal.m4}). Alternatively, you can put separate macros in an +@file{m4} subdirectory, and put @samp{ACLOCAL_AMFLAGS = -I m4} in your +@file{Makefile.am} file so that the @samp{aclocal} program will be able +to find them. + +The different macro prefixes indicate which tool defines the macro. +Macros which start with @samp{AC_} are part of autoconf. Macros which +start with @samp{AM_} are provided by automake or libtool. + +@node Write Makefile.am +@section Write Makefile.am +@cindex @file{Makefile.am}, writing + +You must write the file @file{Makefile.am}. This is an automake input +file, and the automake manual describes in detail what this file should +look like. + +The automake commands in @file{Makefile.am} mostly look like variable +assignments in a @file{Makefile}. automake recognizes special variable +names, and automatically add make rules to the output as needed. + +There will be one @file{Makefile.am} file for each directory in your +package. For each directory with subdirectories, the @file{Makefile.am} +file should contain the line +@smallexample +SUBDIRS = @var{dir} @var{dir} @dots{} +@end smallexample +@noindent +where each @var{dir} is the name of a subdirectory. + +For each @file{Makefile.am}, there should be a corresponding +@file{Makefile} in the @samp{AC_OUTPUT} macro in @file{configure.in}. + +Every @file{Makefile.am} written at Cygnus should contain the line +@smallexample +AUTOMAKE_OPTIONS = cygnus +@end smallexample +@noindent +This puts automake into Cygnus mode. See the automake manual for +details. + +You may to include the version number of @samp{automake} that you are +using on the @samp{AUTOMAKE_OPTIONS} line. For example, +@smallexample +AUTOMAKE_OPTIONS = cygnus 1.3 +@end smallexample +@noindent +This will prevent users from running an earlier version of +@samp{automake} and perhaps getting an invalid @file{Makefile.in}. + +If your package builds a program, then in the directory where that +program is built you will normally want a line like +@smallexample +bin_PROGRAMS = @var{program} +@end smallexample +@noindent +where @var{program} is the name of the program. You will then want a +line like +@smallexample +@var{program}_SOURCES = @var{file} @var{file} @dots{} +@end smallexample +@noindent +where each @var{file} is the name of a source file to link into the +program (e.g., @samp{foo.c}). + +If your package builds a library, and you do not want the library to +ever be built as a shared library, then in the directory where that +library is built you will normally want a line like +@smallexample +lib_LIBRARIES = lib@var{name}.a +@end smallexample +@noindent +where @samp{lib@var{name}.a} is the name of the library. You will then +want a line like +@smallexample +lib@var{name}_a_SOURCES = @var{file} @var{file} @dots{} +@end smallexample +@noindent +where each @var{file} is the name of a source file to add to the +library. + +If your package builds a library, and you want to permit building the +library as a shared library, then in the directory where that library is +built you will normally want a line like +@smallexample +lib_LTLIBRARIES = lib@var{name}.la +@end smallexample +The use of @samp{LTLIBRARIES}, and the @samp{.la} extension, indicate a +library to be built using libtool. As usual, you will then want a line +like +@smallexample +lib@var{name}_la_SOURCES = @var{file} @var{file} @dots{} +@end smallexample + +The strings @samp{bin} and @samp{lib} that appear above in +@samp{bin_PROGRAMS} and @samp{lib_LIBRARIES} are not arbitrary. They +refer to particular directories, which may be set by the @samp{--bindir} +and @samp{--libdir} options to @file{configure}. If those options are +not used, the default values are based on the @samp{--prefix} or +@samp{--exec-prefix} options to @file{configure}. It is possible to use +other names if the program or library should be installed in some other +directory. + +The @file{Makefile.am} file may also contain almost anything that may +appear in a normal @file{Makefile}. automake also supports many other +special variables, as well as conditionals. + +See the automake manual for more information. + +@node Write acconfig.h +@section Write acconfig.h +@cindex @file{acconfig.h}, writing + +If you are generating a portability header file, (i.e., you are using +@samp{AM_CONFIG_HEADER} in @file{configure.in}), then you will have to +write a @file{acconfig.h} file. It will have to contain the following +lines. + +@smallexample +/* Name of package. */ +#undef PACKAGE + +/* Version of package. */ +#undef VERSION +@end smallexample + +This requirement is really a bug in the system, and the requirement may +be eliminated at some later date. + +The @file{acconfig.h} file will also similar comment and @samp{#undef} +lines for any unusual macros in the @file{configure.in} file, including +any macro which appears in a @samp{AC_DEFINE} macro. + +In particular, if you are writing a GNU package and therefore include +@samp{AC_DEFINE(_GNU_SOURCE)} in @file{configure.in} as suggested above, +you will need lines like this in @file{acconfig.h}: +@smallexample +/* Enable GNU extensions. */ +#undef _GNU_SOURCE +@end smallexample + +Normally the @samp{autoheader} program will inform you of any such +requirements by printing an error message when it is run. However, if +you do anything particular odd in your @file{configure.in} file, you +will have to make sure that the right entries appear in +@file{acconfig.h}, since otherwise the results of the tests may not be +available in the @file{config.h} file which your code will use. + +(Thee @samp{PACKAGE} and @samp{VERSION} lines are not required if you +are not using automake, and in that case you may not need a +@file{acconfig.h} file at all). + +@node Generate files +@section Generate files + +Once you have written @file{configure.in}, @file{Makefile.am}, +@file{acconfig.h}, and possibly @file{acinclude.m4}, you must use +autoconf and automake programs to produce the first versions of the +generated files. This is done by executing the following sequence of +commands. + +@smallexample +aclocal +autoconf +autoheader +automake +@end smallexample + +The @samp{aclocal} and @samp{automake} commands are part of the automake +package, and the @samp{autoconf} and @samp{autoheader} commands are part +of the autoconf package. + +If you are using a @file{m4} subdirectory for your macros, you will need +to use the @samp{-I m4} option when you run @samp{aclocal}. + +If you are not using the Cygnus tree, use the @samp{-a} option when +running @samp{automake} command in order to copy the required support +files into your source directory. + +If you are using libtool, you must build and install the libtool package +with the same @samp{--prefix} and @samp{--exec-prefix} options as you +used with the autoconf and automake packages. You must do this before +running any of the above commands. If you are not using the Cygnus +tree, you will need to run the @samp{libtoolize} program to copy the +libtool support files into your directory. + +Once you have managed to run these commands without getting any errors, +you should create a new empty directory, and run the @samp{configure} +script which will have been created by @samp{autoconf} with the +@samp{--enable-maintainer-mode} option. This will give you a set of +Makefiles which will include rules to automatically rebuild all the +generated files. + +After doing that, whenever you have changed some of the input files and +want to regenerated the other files, go to your object directory and run +@samp{make}. Doing this is more reliable than trying to rebuild the +files manually, because there are complex order dependencies and it is +easy to forget something. + +@node Getting Started Example +@section Example + +Let's consider a trivial example. + +Suppose we want to write a simple version of @samp{touch}. Our program, +which we will call @samp{poke}, will take a single file name argument, +and use the @samp{utime} system call to set the modification and access +times of the file to the current time. We want this program to be +highly portable. + +We'll first see what this looks like without using autoconf and +automake, and then see what it looks like with them. + +@menu +* Getting Started Example 1:: First Try. +* Getting Started Example 2:: Second Try. +* Getting Started Example 3:: Third Try. +* Generate Files in Example:: Generate Files. +@end menu + +@node Getting Started Example 1 +@subsection First Try + +Here is our first try at @samp{poke.c}. Note that we've written it +without ANSI/ISO C prototypes, since we want it to be highly portable. + +@example +#include <stdio.h> +#include <stdlib.h> +#include <sys/types.h> +#include <utime.h> + +int +main (argc, argv) + int argc; + char **argv; +@{ + if (argc != 2) + @{ + fprintf (stderr, "Usage: poke file\n"); + exit (1); + @} + + if (utime (argv[1], NULL) < 0) + @{ + perror ("utime"); + exit (1); + @} + + exit (0); +@} +@end example + +We also write a simple @file{Makefile}. + +@example +CC = gcc +CFLAGS = -g -O2 + +all: poke + +poke: poke.o + $(CC) -o poke $(CFLAGS) $(LDFLAGS) poke.o +@end example + +So far, so good. + +Unfortunately, there are a few problems. + +On older Unix systems derived from BSD 4.3, the @samp{utime} system call +does not accept a second argument of @samp{NULL}. On those systems, we +need to pass a pointer to @samp{struct utimbuf} structure. +Unfortunately, even older systems don't define that structure; on those +systems, we need to pass an array of two @samp{long} values. + +The header file @file{stdlib.h} was invented by ANSI C, and older +systems don't have a copy. We included it above to get a declaration of +@samp{exit}. + +We can find some of these portability problems by running +@samp{autoscan}, which will create a @file{configure.scan} file which we +can use as a prototype for our @file{configure.in} file. I won't show +the output, but it will notice the potential problems with @samp{utime} +and @file{stdlib.h}. + +In our @file{Makefile}, we don't provide any way to install the program. +This doesn't matter much for such a simple example, but a real program +will need an @samp{install} target. For that matter, we will also want +a @samp{clean} target. + +@node Getting Started Example 2 +@subsection Second Try + +Here is our second try at this program. + +We modify @file{poke.c} to use preprocessor macros to control what +features are available. (I've cheated a bit by using the same macro +names which autoconf will use). + +@example +#include <stdio.h> + +#ifdef STDC_HEADERS +#include <stdlib.h> +#endif + +#include <sys/types.h> + +#ifdef HAVE_UTIME_H +#include <utime.h> +#endif + +#ifndef HAVE_UTIME_NULL + +#include <time.h> + +#ifndef HAVE_STRUCT_UTIMBUF + +struct utimbuf +@{ + long actime; + long modtime; +@}; + +#endif + +static int +utime_now (file) + char *file; +@{ + struct utimbuf now; + + now.actime = now.modtime = time (NULL); + return utime (file, &now); +@} + +#define utime(f, p) utime_now (f) + +#endif /* HAVE_UTIME_NULL */ + +int +main (argc, argv) + int argc; + char **argv; +@{ + if (argc != 2) + @{ + fprintf (stderr, "Usage: poke file\n"); + exit (1); + @} + + if (utime (argv[1], NULL) < 0) + @{ + perror ("utime"); + exit (1); + @} + + exit (0); +@} +@end example + +Here is the associated @file{Makefile}. We've added support for the +preprocessor flags we use. We've also added @samp{install} and +@samp{clean} targets. + +@example +# Set this to your installation directory. +bindir = /usr/local/bin + +# Uncomment this if you have the standard ANSI/ISO C header files. +# STDC_HDRS = -DSTDC_HEADERS + +# Uncomment this if you have utime.h. +# UTIME_H = -DHAVE_UTIME_H + +# Uncomment this if utime (FILE, NULL) works on your system. +# UTIME_NULL = -DHAVE_UTIME_NULL + +# Uncomment this if struct utimbuf is defined in utime.h. +# UTIMBUF = -DHAVE_STRUCT_UTIMBUF + +CC = gcc +CFLAGS = -g -O2 + +ALL_CFLAGS = $(STDC_HDRS) $(UTIME_H) $(UTIME_NULL) $(UTIMBUF) $(CFLAGS) + +all: poke + +poke: poke.o + $(CC) -o poke $(ALL_CFLAGS) $(LDFLAGS) poke.o + +.c.o: + $(CC) -c $(ALL_CFLAGS) poke.c + +install: poke + cp poke $(bindir)/poke + +clean: + rm poke poke.o +@end example + +Some problems with this approach should be clear. + +Users who want to compile poke will have to know how @samp{utime} works +on their systems, so that they can uncomment the @file{Makefile} +correctly. + +The installation is done using @samp{cp}, but many systems have an +@samp{install} program which may be used, and which supports optional +features such as stripping debugging information out of the installed +binary. + +The use of @file{Makefile} variables like @samp{CC}, @samp{CFLAGS} and +@samp{LDFLAGS} follows the requirements of the GNU standards. This is +convenient for all packages, since it reduces surprises for users. +However, it is easy to get the details wrong, and wind up with a +slightly nonstandard distribution. + +@node Getting Started Example 3 +@subsection Third Try + +For our third try at this program, we will write a @file{configure.in} +script to discover the configuration features on the host system, rather +than requiring the user to edit the @file{Makefile}. We will also write +a @file{Makefile.am} rather than a @file{Makefile}. + +The only change to @file{poke.c} is to add a line at the start of the +file: +@smallexample +#include "config.h" +@end smallexample + +The new @file{configure.in} file is as follows. + +@example +AC_INIT(poke.c) +AM_INIT_AUTOMAKE(poke, 1.0) +AM_CONFIG_HEADER(config.h:config.in) +AC_PROG_CC +AC_HEADER_STDC +AC_CHECK_HEADERS(utime.h) +AC_EGREP_HEADER(utimbuf, utime.h, AC_DEFINE(HAVE_STRUCT_UTIMBUF)) +AC_FUNC_UTIME_NULL +AC_OUTPUT(Makefile) +@end example + +The first four macros in this file, and the last one, were described +above; see @ref{Write configure.in}. If we omit these macros, then when +we run @samp{automake} we will get a reminder that we need them. + +The other macros are standard autoconf macros. + +@table @samp +@item AC_HEADER_STDC +Check for standard C headers. +@item AC_CHECK_HEADERS +Check whether a particular header file exists. +@item AC_EGREP_HEADER +Check for a particular string in a particular header file, in this case +checking for @samp{utimbuf} in @file{utime.h}. +@item AC_FUNC_UTIME_NULL +Check whether @samp{utime} accepts a NULL second argument to set the +file change time to the current time. +@end table + +See the autoconf manual for a more complete description. + +The new @file{Makefile.am} file is as follows. Note how simple this is +compared to our earlier @file{Makefile}. + +@example +bin_PROGRAMS = poke + +poke_SOURCES = poke.c +@end example + +This means that we should build a single program name @samp{poke}. It +should be installed in the binary directory, which we called +@samp{bindir} earlier. The program @samp{poke} is built from the source +file @file{poke.c}. + +We must also write a @file{acconfig.h} file. Besides @samp{PACKAGE} and +@samp{VERSION}, which must be mentioned for all packages which use +automake, we must include @samp{HAVE_STRUCT_UTIMBUF}, since we mentioned +it in an @samp{AC_DEFINE}. + +@example +/* Name of package. */ +#undef PACKAGE + +/* Version of package. */ +#undef VERSION + +/* Whether utime.h defines struct utimbuf. */ +#undef HAVE_STRUCT_UTIMBUF +@end example + +@node Generate Files in Example +@subsection Generate Files + +We must now generate the other files, using the following commands. + +@smallexample +aclocal +autoconf +autoheader +automake +@end smallexample + +When we run @samp{autoheader}, it will remind us of any macros we forgot +to add to @file{acconfig.h}. + +When we run @samp{automake}, it will want to add some files to our +distribution. It will add them automatically if we use the +@samp{--add-missing} option. + +By default, @samp{automake} will run in GNU mode, which means that it +will want us to create certain additional files; as of this writing, it +will want @file{NEWS}, @file{README}, @file{AUTHORS}, and +@file{ChangeLog}, all of which are files which should appear in a +standard GNU distribution. We can either add those files, or run +@samp{automake} with the @samp{--foreign} option. + +Running these tools will generate the following files, all of which are +described in the next chapter. + +@itemize @bullet +@item +@file{aclocal.m4} +@item +@file{configure} +@item +@file{config.in} +@item +@file{Makefile.in} +@item +@file{stamp-h.in} +@end itemize + +@node Files +@chapter Files + +As was seen in the previous chapter, the GNU configure and build system +uses a number of different files. The developer must write a few files. +The others are generated by various tools. + +The system is rather flexible, and can be used in many different ways. +In describing the files that it uses, I will describe the common case, +and mention some other cases that may arise. + +@menu +* Developer Files:: Developer Files. +* Build Files:: Build Files. +* Support Files:: Support Files. +@end menu + +@node Developer Files +@section Developer Files + +This section describes the files written or generated by the developer +of a package. + +@menu +* Developer Files Picture:: Developer Files Picture. +* Written Developer Files:: Written Developer Files. +* Generated Developer Files:: Generated Developer Files. +@end menu + +@node Developer Files Picture +@subsection Developer Files Picture + +Here is a picture of the files which are written by the developer, the +generated files which would be included with a complete source +distribution, and the tools which create those files. +@ifinfo +The file names are plain text and the tool names are enclosed by +@samp{*} characters +@end ifinfo +@ifnotinfo +The file names are in rectangles with square corners and the tool names +are in rectangles with rounded corners +@end ifnotinfo +(e.g., @samp{autoheader} is the name of a tool, not the name of a file). + +@image{configdev} + +@node Written Developer Files +@subsection Written Developer Files + +The following files would be written by the developer. + +@table @file +@item configure.in +@cindex @file{configure.in} +This is the configuration script. This script contains invocations of +autoconf macros. It may also contain ordinary shell script code. This +file will contain feature tests for portability issues. The last thing +in the file will normally be an @samp{AC_OUTPUT} macro listing which +files to create when the builder runs the configure script. This file +is always required when using the GNU configure system. @xref{Write +configure.in}. + +@item Makefile.am +@cindex @file{Makefile.am} +This is the automake input file. It describes how the code should be +built. It consists of definitions of automake variables. It may also +contain ordinary Makefile targets. This file is only needed when using +automake (newer tools normally use automake, but there are still older +tools which have not been converted, in which the developer writes +@file{Makefile.in} directly). @xref{Write Makefile.am}. + +@item acconfig.h +@cindex @file{acconfig.h} +When the configure script creates a portability header file, by using +@samp{AM_CONFIG_HEADER} (or, if not using automake, +@samp{AC_CONFIG_HEADER}), this file is used to describe macros which are +not recognized by the @samp{autoheader} command. This is normally a +fairly uninteresting file, consisting of a collection of @samp{#undef} +lines with comments. Normally any call to @samp{AC_DEFINE} in +@file{configure.in} will require a line in this file. @xref{Write +acconfig.h}. + +@item acinclude.m4 +@cindex @file{acinclude.m4} +This file is not always required. It defines local autoconf macros. +These macros may then be used in @file{configure.in}. If you don't need +any local autoconf macros, then you don't need this file at all. In +fact, in general, you never need local autoconf macros, since you can +put everything in @file{configure.in}, but sometimes a local macro is +convenient. + +Newer tools may omit @file{acinclude.m4}, and instead use a +subdirectory, typically named @file{m4}, and define +@samp{ACLOCAL_AMFLAGS = -I m4} in @file{Makefile.am} to force +@samp{aclocal} to look there for macro definitions. The macro +definitions are then placed in separate files in that directory. + +The @file{acinclude.m4} file is only used when using automake; in older +tools, the developer writes @file{aclocal.m4} directly, if it is needed. +@end table + +@node Generated Developer Files +@subsection Generated Developer Files + +The following files would be generated by the developer. + +When using automake, these files are normally not generated manually +after the first time. Instead, the generated @file{Makefile} contains +rules to automatically rebuild the files as required. When +@samp{AM_MAINTAINER_MODE} is used in @file{configure.in} (the normal +case in Cygnus code), the automatic rebuilding rules will only be +defined if you configure using the @samp{--enable-maintainer-mode} +option. + +When using automatic rebuilding, it is important to ensure that all the +various tools have been built and installed on your @samp{PATH}. Using +automatic rebuilding is highly recommended, so much so that I'm not +going to explain what you have to do if you don't use it. + +@table @file +@item configure +@cindex @file{configure} +This is the configure script which will be run when building the +package. This is generated by @samp{autoconf} from @file{configure.in} +and @file{aclocal.m4}. This is a shell script. + +@item Makefile.in +@cindex @file{Makefile.in} +This is the file which the configure script will turn into the +@file{Makefile} at build time. This file is generated by +@samp{automake} from @file{Makefile.am}. If you aren't using automake, +you must write this file yourself. This file is pretty much a normal +@file{Makefile}, with some configure substitutions for certain +variables. + +@item aclocal.m4 +@cindex @file{aclocal.m4} +This file is created by the @samp{aclocal} program, based on the +contents of @file{configure.in} and @file{acinclude.m4} (or, as noted in +the description of @file{acinclude.m4} above, on the contents of an +@file{m4} subdirectory). This file contains definitions of autoconf +macros which @samp{autoconf} will use when generating the file +@file{configure}. These autoconf macros may be defined by you in +@file{acinclude.m4} or they may be defined by other packages such as +automake, libtool or gettext. If you aren't using automake, you will +normally write this file yourself; in that case, if @file{configure.in} +uses only standard autoconf macros, this file will not be needed at all. + +@item config.in +@cindex @file{config.in} +@cindex @file{config.h.in} +This file is created by @samp{autoheader} based on @file{acconfig.h} and +@file{configure.in}. At build time, the configure script will define +some of the macros in it to create @file{config.h}, which may then be +included by your program. This permits your C code to use preprocessor +conditionals to change its behaviour based on the characteristics of the +host system. This file may also be called @file{config.h.in}. + +@item stamp.h-in +@cindex @file{stamp-h.in} +This rather uninteresting file, which I omitted from the picture, is +generated by @samp{automake}. It always contains the string +@samp{timestamp}. It is used as a timestamp file indicating whether +@file{config.in} is up to date. Using a timestamp file means that +@file{config.in} can be marked as up to date without actually changing +its modification time. This is useful since @file{config.in} depends +upon @file{configure.in}, but it is easy to change @file{configure.in} +in a way which does not affect @file{config.in}. +@end table + +@node Build Files +@section Build Files + +This section describes the files which are created at configure and +build time. These are the files which somebody who builds the package +will see. + +Of course, the developer will also build the package. The distinction +between developer files and build files is not that the developer does +not see the build files, but that somebody who only builds the package +does not have to worry about the developer files. + +@menu +* Build Files Picture:: Build Files Picture. +* Build Files Description:: Build Files Description. +@end menu + +@node Build Files Picture +@subsection Build Files Picture + +Here is a picture of the files which will be created at build time. +@file{config.status} is both a created file and a shell script which is +run to create other files, and the picture attempts to show that. + +@image{configbuild} + +@node Build Files Description +@subsection Build Files Description + +This is a description of the files which are created at build time. + +@table @file +@item config.status +@cindex @file{config.status} +The first step in building a package is to run the @file{configure} +script. The @file{configure} script will create the file +@file{config.status}, which is itself a shell script. When you first +run @file{configure}, it will automatically run @file{config.status}. +An @file{Makefile} derived from an automake generated @file{Makefile.in} +will contain rules to automatically run @file{config.status} again when +necessary to recreate certain files if their inputs change. + +@item Makefile +@cindex @file{Makefile} +This is the file which make will read to build the program. The +@file{config.status} script will transform @file{Makefile.in} into +@file{Makefile}. + +@item config.h +@cindex @file{config.h} +This file defines C preprocessor macros which C code can use to adjust +its behaviour on different systems. The @file{config.status} script +will transform @file{config.in} into @file{config.h}. + +@item config.cache +@cindex @file{config.cache} +This file did not fit neatly into the picture, and I omitted it. It is +used by the @file{configure} script to cache results between runs. This +can be an important speedup. If you modify @file{configure.in} in such +a way that the results of old tests should change (perhaps you have +added a new library to @samp{LDFLAGS}), then you will have to remove +@file{config.cache} to force the tests to be rerun. + +The autoconf manual explains how to set up a site specific cache file. +This can speed up running @file{configure} scripts on your system. + +@item stamp.h +@cindex @file{stamp-h} +This file, which I omitted from the picture, is similar to +@file{stamp-h.in}. It is used as a timestamp file indicating whether +@file{config.h} is up to date. This is useful since @file{config.h} +depends upon @file{config.status}, but it is easy for +@file{config.status} to change in a way which does not affect +@file{config.h}. +@end table + +@node Support Files +@section Support Files + +The GNU configure and build system requires several support files to be +included with your distribution. You do not normally need to concern +yourself with these. If you are using the Cygnus tree, most are already +present. Otherwise, they will be installed with your source by +@samp{automake} (with the @samp{--add-missing} option) and +@samp{libtoolize}. + +You don't have to put the support files in the top level directory. You +can put them in a subdirectory, and use the @samp{AC_CONFIG_AUX_DIR} +macro in @file{configure.in} to tell @samp{automake} and the +@file{configure} script where they are. + +In this section, I describe the support files, so that you can know what +they are and why they are there. + +@table @file +@item ABOUT-NLS +Added by automake if you are using gettext. This is a documentation +file about the gettext project. +@item ansi2knr.c +Used by an automake generated @file{Makefile} if you put @samp{ansi2knr} +in @samp{AUTOMAKE_OPTIONS} in @file{Makefile.am}. This permits +compiling ANSI C code with a K&R C compiler. +@item ansi2knr.1 +The man page which goes with @file{ansi2knr.c}. +@item config.guess +A shell script which determines the configuration name for the system on +which it is run. +@item config.sub +A shell script which canonicalizes a configuration name entered by a +user. +@item elisp-comp +Used to compile Emacs LISP files. +@item install-sh +A shell script which installs a program. This is used if the configure +script can not find an install binary. +@item ltconfig +Used by libtool. This is a shell script which configures libtool for +the particular system on which it is used. +@item ltmain.sh +Used by libtool. This is the actual libtool script which is used, after +it is configured by @file{ltconfig} to build a library. +@item mdate-sh +A shell script used by an automake generated @file{Makefile} to pretty +print the modification time of a file. This is used to maintain version +numbers for texinfo files. +@item missing +A shell script used if some tool is missing entirely. This is used by +an automake generated @file{Makefile} to avoid certain sorts of +timestamp problems. +@item mkinstalldirs +A shell script which creates a directory, including all parent +directories. This is used by an automake generated @file{Makefile} +during installation. +@item texinfo.tex +Required if you have any texinfo files. This is used when converting +Texinfo files into DVI using @samp{texi2dvi} and @TeX{}. +@item ylwrap +A shell script used by an automake generated @file{Makefile} to run +programs like @samp{bison}, @samp{yacc}, @samp{flex}, and @samp{lex}. +These programs default to producing output files with a fixed name, and +the @file{ylwrap} script runs them in a subdirectory to avoid file name +conflicts when using a parallel make program. +@end table + +@node Configuration Names +@chapter Configuration Names +@cindex configuration names +@cindex configuration triplets +@cindex triplets +@cindex host names +@cindex host triplets +@cindex canonical system names +@cindex system names +@cindex system types + +The GNU configure system names all systems using a @dfn{configuration +name}. All such names used to be triplets (they may now contain four +parts in certain cases), and the term @dfn{configuration triplet} is +still seen. + +@menu +* Configuration Name Definition:: Configuration Name Definition. +* Using Configuration Names:: Using Configuration Names. +@end menu + +@node Configuration Name Definition +@section Configuration Name Definition + +This is a string of the form +@var{cpu}-@var{manufacturer}-@var{operating_system}. In some cases, +this is extended to a four part form: +@var{cpu}-@var{manufacturer}-@var{kernel}-@var{operating_system}. + +When using a configuration name in a configure option, it is normally +not necessary to specify an entire name. In particular, the +@var{manufacturer} field is often omitted, leading to strings such as +@samp{i386-linux} or @samp{sparc-sunos}. The shell script +@file{config.sub} will translate these shortened strings into the +canonical form. autoconf will arrange for @file{config.sub} to be run +automatically when it is needed. + +The fields of a configuration name are as follows: + +@table @var +@item cpu +The type of processor. This is typically something like @samp{i386} or +@samp{sparc}. More specific variants are used as well, such as +@samp{mipsel} to indicate a little endian MIPS processor. +@item manufacturer +A somewhat freeform field which indicates the manufacturer of the +system. This is often simply @samp{unknown}. Other common strings are +@samp{pc} for an IBM PC compatible system, or the name of a workstation +vendor, such as @samp{sun}. +@item operating_system +The name of the operating system which is run on the system. This will +be something like @samp{solaris2.5} or @samp{irix6.3}. There is no +particular restriction on the version number, and strings like +@samp{aix4.1.4.0} are seen. For an embedded system, which has no +operating system, this field normally indicates the type of object file +format, such as @samp{elf} or @samp{coff}. +@item kernel +This is used mainly for GNU/Linux. A typical GNU/Linux configuration +name is @samp{i586-pc-linux-gnulibc1}. In this case the kernel, +@samp{linux}, is separated from the operating system, @samp{gnulibc1}. +@end table + +The shell script @file{config.guess} will normally print the correct +configuration name for the system on which it is run. It does by +running @samp{uname} and by examining other characteristics of the +system. + +Because @file{config.guess} can normally determine the configuration +name for a machine, it is normally only necessary to specify a +configuration name when building a cross-compiler or when building using +a cross-compiler. + +@node Using Configuration Names +@section Using Configuration Names + +A configure script will sometimes have to make a decision based on a +configuration name. You will need to do this if you have to compile +code differently based on something which can not be tested using a +standard autoconf feature test. + +It is normally better to test for particular features, rather than to +test for a particular system. This is because as Unix evolves, +different systems copy features from one another. Even if you need to +determine whether the feature is supported based on a configuration +name, you should define a macro which describes the feature, rather than +defining a macro which describes the particular system you are on. + +Testing for a particular system is normally done using a case statement +in @file{configure.in}. The case statement might look something like +the following, assuming that @samp{host} is a shell variable holding a +canonical configuration name (which will be the case if +@file{configure.in} uses the @samp{AC_CANONICAL_HOST} or +@samp{AC_CANONICAL_SYSTEM} macro). + +@smallexample +case "$@{host@}" in +i[3-7]86-*-linux-gnu*) do something ;; +sparc*-sun-solaris2.[56789]*) do something ;; +sparc*-sun-solaris*) do something ;; +mips*-*-elf*) do something ;; +esac +@end smallexample + +It is particularly important to use @samp{*} after the operating system +field, in order to match the version number which will be generated by +@file{config.guess}. + +In most cases you must be careful to match a range of processor types. +For most processor families, a trailing @samp{*} suffices, as in +@samp{mips*} above. For the i386 family, something along the lines of +@samp{i[3-7]86} suffices at present. For the m68k family, you will +need something like @samp{m68*}. Of course, if you do not need to match +on the processor, it is simpler to just replace the entire field by a +@samp{*}, as in @samp{*-*-irix*}. + +@node Cross Compilation Tools +@chapter Cross Compilation Tools +@cindex cross tools + +The GNU configure and build system can be used to build @dfn{cross +compilation} tools. A cross compilation tool is a tool which runs on +one system and produces code which runs on another system. + +@menu +* Cross Compilation Concepts:: Cross Compilation Concepts. +* Host and Target:: Host and Target. +* Using the Host Type:: Using the Host Type. +* Specifying the Target:: Specifying the Target. +* Using the Target Type:: Using the Target Type. +* Cross Tools in the Cygnus Tree:: Cross Tools in the Cygnus Tree +@end menu + +@node Cross Compilation Concepts +@section Cross Compilation Concepts + +@cindex cross compiler +A compiler which produces programs which run on a different system is a +cross compilation compiler, or simply a @dfn{cross compiler}. +Similarly, we speak of cross assemblers, cross linkers, etc. + +In the normal case, a compiler produces code which runs on the same +system as the one on which the compiler runs. When it is necessary to +distinguish this case from the cross compilation case, such a compiler +is called a @dfn{native compiler}. Similarly, we speak of native +assemblers, etc. + +Although the debugger is not strictly speaking a compilation tool, it is +nevertheless meaningful to speak of a cross debugger: a debugger which +is used to debug code which runs on another system. Everything that is +said below about configuring cross compilation tools applies to the +debugger as well. + +@node Host and Target +@section Host and Target +@cindex host system +@cindex target system + +When building cross compilation tools, there are two different systems +involved: the system on which the tools will run, and the system for +which the tools generate code. + +The system on which the tools will run is called the @dfn{host} system. + +The system for which the tools generate code is called the @dfn{target} +system. + +For example, suppose you have a compiler which runs on a GNU/Linux +system and generates ELF programs for a MIPS embedded system. In this +case the GNU/Linux system is the host, and the MIPS ELF system is the +target. Such a compiler could be called a GNU/Linux cross MIPS ELF +compiler, or, equivalently, a @samp{i386-linux-gnu} cross +@samp{mips-elf} compiler. + +Naturally, most programs are not cross compilation tools. For those +programs, it does not make sense to speak of a target. It only makes +sense to speak of a target for tools like @samp{gcc} or the +@samp{binutils} which actually produce running code. For example, it +does not make sense to speak of the target of a tool like @samp{bison} +or @samp{make}. + +Most cross compilation tools can also serve as native tools. For a +native compilation tool, it is still meaningful to speak of a target. +For a native tool, the target is the same as the host. For example, for +a GNU/Linux native compiler, the host is GNU/Linux, and the target is +also GNU/Linux. + +@node Using the Host Type +@section Using the Host Type + +In almost all cases the host system is the system on which you run the +@samp{configure} script, and on which you build the tools (for the case +when they differ, @pxref{Canadian Cross}). + +@cindex @samp{AC_CANONICAL_HOST} +If your configure script needs to know the configuration name of the +host system, and the package is not a cross compilation tool and +therefore does not have a target, put @samp{AC_CANONICAL_HOST} in +@file{configure.in}. This macro will arrange to define a few shell +variables when the @samp{configure} script is run. + +@table @samp +@item host +The canonical configuration name of the host. This will normally be +determined by running the @file{config.guess} shell script, although the +user is permitted to override this by using an explicit @samp{--host} +option. +@item host_alias +In the unusual case that the user used an explicit @samp{--host} option, +this will be the argument to @samp{--host}. In the normal case, this +will be the same as the @samp{host} variable. +@item host_cpu +@itemx host_vendor +@itemx host_os +The first three parts of the canonical configuration name. +@end table + +The shell variables may be used by putting shell code in +@file{configure.in}. For an example, see @ref{Using Configuration +Names}. + +@node Specifying the Target +@section Specifying the Target + +By default, the @samp{configure} script will assume that the target is +the same as the host. This is the more common case; for example, it +leads to a native compiler rather than a cross compiler. + +@cindex @samp{--target} option +@cindex target option +@cindex configure target +If you want to build a cross compilation tool, you must specify the +target explicitly by using the @samp{--target} option when you run +@samp{configure}. The argument to @samp{--target} is the configuration +name of the system for which you wish to generate code. +@xref{Configuration Names}. + +For example, to build tools which generate code for a MIPS ELF embedded +system, you would use @samp{--target mips-elf}. + +@node Using the Target Type +@section Using the Target Type + +@cindex @samp{AC_CANONICAL_SYSTEM} +When writing @file{configure.in} for a cross compilation tool, you will +need to use information about the target. To do this, put +@samp{AC_CANONICAL_SYSTEM} in @file{configure.in}. + +@samp{AC_CANONICAL_SYSTEM} will look for a @samp{--target} option and +canonicalize it using the @file{config.sub} shell script. It will also +run @samp{AC_CANONICAL_HOST} (@pxref{Using the Host Type}). + +The target type will be recorded in the following shell variables. Note +that the host versions of these variables will also be defined by +@samp{AC_CANONICAL_HOST}. + +@table @samp +@item target +The canonical configuration name of the target. +@item target_alias +The argument to the @samp{--target} option. If the user did not specify +a @samp{--target} option, this will be the same as @samp{host_alias}. +@item target_cpu +@itemx target_vendor +@itemx target_os +The first three parts of the canonical target configuration name. +@end table + +Note that if @samp{host} and @samp{target} are the same string, you can +assume a native configuration. If they are different, you can assume a +cross configuration. + +It is arguably possible for @samp{host} and @samp{target} to represent +the same system, but for the strings to not be identical. For example, +if @samp{config.guess} returns @samp{sparc-sun-sunos4.1.4}, and somebody +configures with @samp{--target sparc-sun-sunos4.1}, then the slight +differences between the two versions of SunOS may be unimportant for +your tool. However, in the general case it can be quite difficult to +determine whether the differences between two configuration names are +significant or not. Therefore, by convention, if the user specifies a +@samp{--target} option without specifying a @samp{--host} option, it is +assumed that the user wants to configure a cross compilation tool. + +The variables @samp{target} and @samp{target_alias} should be handled +differently. + +In general, whenever the user may actually see a string, +@samp{target_alias} should be used. This includes anything which may +appear in the file system, such as a directory name or part of a tool +name. It also includes any tool output, unless it is clearly labelled +as the canonical target configuration name. This permits the user to +use the @samp{--target} option to specify how the tool will appear to +the outside world. + +On the other hand, when checking for characteristics of the target +system, @samp{target} should be used. This is because a wide variety of +@samp{--target} options may map into the same canonical configuration +name. You should not attempt to duplicate the canonicalization done by +@samp{config.sub} in your own code. + +By convention, cross tools are installed with a prefix of the argument +used with the @samp{--target} option, also known as @samp{target_alias} +(@pxref{Using the Target Type}). If the user does not use the +@samp{--target} option, and thus is building a native tool, no prefix is +used. + +For example, if gcc is configured with @samp{--target mips-elf}, then +the installed binary will be named @samp{mips-elf-gcc}. If gcc is +configured without a @samp{--target} option, then the installed binary +will be named @samp{gcc}. + +The autoconf macro @samp{AC_ARG_PROGRAM} will handle this for you. If +you are using automake, no more need be done; the programs will +automatically be installed with the correct prefixes. Otherwise, see +the autoconf documentation for @samp{AC_ARG_PROGRAM}. + +@node Cross Tools in the Cygnus Tree +@section Cross Tools in the Cygnus Tree + +The Cygnus tree is used for various packages including gdb, the GNU +binutils, and egcs. It is also, of course, used for Cygnus releases. + +In the Cygnus tree, the top level @file{configure} script uses the old +Cygnus configure system, not autoconf. The top level @file{Makefile.in} +is written to build packages based on what is in the source tree, and +supports building a large number of tools in a single +@samp{configure}/@samp{make} step. + +The Cygnus tree may be configured with a @samp{--target} option. The +@samp{--target} option applies recursively to every subdirectory, and +permits building an entire set of cross tools at once. + +@menu +* Host and Target Libraries:: Host and Target Libraries. +* Target Library Configure Scripts:: Target Library Configure Scripts. +* Make Targets in Cygnus Tree:: Make Targets in Cygnus Tree. +* Target libiberty:: Target libiberty +@end menu + +@node Host and Target Libraries +@subsection Host and Target Libraries + +The Cygnus tree distinguishes host libraries from target libraries. + +Host libraries are built with the compiler used to build the programs +which run on the host, which is called the host compiler. This includes +libraries such as @samp{bfd} and @samp{tcl}. These libraries are built +with the host compiler, and are linked into programs like the binutils +or gcc which run on the host. + +Target libraries are built with the target compiler. If gcc is present +in the source tree, then the target compiler is the gcc that is built +using the host compiler. Target libraries are libraries such as +@samp{newlib} and @samp{libstdc++}. These libraries are not linked into +the host programs, but are instead made available for use with programs +built with the target compiler. + +For the rest of this section, assume that gcc is present in the source +tree, so that it will be used to build the target libraries. + +There is a complication here. The configure process needs to know which +compiler you are going to use to build a tool; otherwise, the feature +tests will not work correctly. The Cygnus tree handles this by not +configuring the target libraries until the target compiler is built. In +order to permit everything to build using a single +@samp{configure}/@samp{make}, the configuration of the target libraries +is actually triggered during the make step. + +When the target libraries are configured, the @samp{--target} option is +not used. Instead, the @samp{--host} option is used with the argument +of the @samp{--target} option for the overall configuration. If no +@samp{--target} option was used for the overall configuration, the +@samp{--host} option will be passed with the output of the +@file{config.guess} shell script. Any @samp{--build} option is passed +down unchanged. + +This translation of configuration options is done because since the +target libraries are compiled with the target compiler, they are being +built in order to run on the target of the overall configuration. By +the definition of host, this means that their host system is the same as +the target system of the overall configuration. + +The same process is used for both a native configuration and a cross +configuration. Even when using a native configuration, the target +libraries will be configured and built using the newly built compiler. +This is particularly important for the C++ libraries, since there is no +reason to assume that the C++ compiler used to build the host tools (if +there even is one) uses the same ABI as the g++ compiler which will be +used to build the target libraries. + +There is one difference between a native configuration and a cross +configuration. In a native configuration, the target libraries are +normally configured and built as siblings of the host tools. In a cross +configuration, the target libraries are normally built in a subdirectory +whose name is the argument to @samp{--target}. This is mainly for +historical reasons. + +To summarize, running @samp{configure} in the Cygnus tree configures all +the host libraries and tools, but does not configure any of the target +libraries. Running @samp{make} then does the following steps: + +@itemize @bullet +@item +Build the host libraries. +@item +Build the host programs, including gcc. Note that we call gcc both a +host program (since it runs on the host) and a target compiler (since it +generates code for the target). +@item +Using the newly built target compiler, configure the target libraries. +@item +Build the target libraries. +@end itemize + +The steps need not be done in precisely this order, since they are +actually controlled by @file{Makefile} targets. + +@node Target Library Configure Scripts +@subsection Target Library Configure Scripts + +There are a few things you must know in order to write a configure +script for a target library. This is just a quick sketch, and beginners +shouldn't worry if they don't follow everything here. + +The target libraries are configured and built using a newly built target +compiler. There may not be any startup files or libraries for this +target compiler. In fact, those files will probably be built as part of +some target library, which naturally means that they will not exist when +your target library is configured. + +This means that the configure script for a target library may not use +any test which requires doing a link. This unfortunately includes many +useful autoconf macros, such as @samp{AC_CHECK_FUNCS}. autoconf macros +which do a compile but not a link, such as @samp{AC_CHECK_HEADERS}, may +be used. + +This is a severe restriction, but normally not a fatal one, as target +libraries can often assume the presence of other target libraries, and +thus know which functions will be available. + +As of this writing, the autoconf macro @samp{AC_PROG_CC} does a link to +make sure that the compiler works. This may fail in a target library, +so target libraries must use a different set of macros to locate the +compiler. See the @file{configure.in} file in a directory like +@file{libiberty} or @file{libgloss} for an example. + +As noted in the previous section, target libraries are sometimes built +in directories which are siblings to the host tools, and are sometimes +built in a subdirectory. The @samp{--with-target-subdir} configure +option will be passed when the library is configured. Its value will be +an empty string if the target library is a sibling. Its value will be +the name of the subdirectory if the target library is in a subdirectory. + +If the overall build is not a native build (i.e., the overall configure +used the @samp{--target} option), then the library will be configured +with the @samp{--with-cross-host} option. The value of this option will +be the host system of the overall build. Recall that the host system of +the library will be the target of the overall build. If the overall +build is a native build, the @samp{--with-cross-host} option will not be +used. + +A library which can be built both standalone and as a target library may +want to install itself into different directories depending upon the +case. When built standalone, or when built native, the library should +be installed in @samp{$(libdir)}. When built as a target library which +is not native, the library should be installed in @samp{$(tooldir)/lib}. +The @samp{--with-cross-host} option may be used to distinguish these +cases. + +This same test of @samp{--with-cross-host} may be used to see whether it +is OK to use link tests in the configure script. If the +@samp{--with-cross-host} option is not used, then the library is being +built either standalone or native, and a link should work. + +@node Make Targets in Cygnus Tree +@subsection Make Targets in Cygnus Tree + +The top level @file{Makefile} in the Cygnus tree defines targets for +every known subdirectory. + +For every subdirectory @var{dir} which holds a host library or program, +the @file{Makefile} target @samp{all-@var{dir}} will build that library +or program. + +There are dependencies among host tools. For example, building gcc +requires first building gas, because the gcc build process invokes the +target assembler. These dependencies are reflected in the top level +@file{Makefile}. + +For every subdirectory @var{dir} which holds a target library, the +@file{Makefile} target @samp{configure-target-@var{dir}} will configure +that library. The @file{Makefile} target @samp{all-target-@var{dir}} +will build that library. + +Every @samp{configure-target-@var{dir}} target depends upon +@samp{all-gcc}, since gcc, the target compiler, is required to configure +the tool. Every @samp{all-target-@var{dir}} target depends upon the +corresponding @samp{configure-target-@var{dir}} target. + +There are several other targets which may be of interest for each +directory: @samp{install-@var{dir}}, @samp{clean-@var{dir}}, and +@samp{check-@var{dir}}. There are also corresponding @samp{target} +versions of these for the target libraries , such as +@samp{install-target-@var{dir}}. + +@node Target libiberty +@subsection Target libiberty + +The @file{libiberty} subdirectory is currently a special case, in that +it is the only directory which is built both using the host compiler and +using the target compiler. + +This is because the files in @file{libiberty} are used when building the +host tools, and they are also incorporated into the @file{libstdc++} +target library as support code. + +This duality does not pose any particular difficulties. It means that +there are targets for both @samp{all-libiberty} and +@samp{all-target-libiberty}. + +In a native configuration, when target libraries are not built in a +subdirectory, the same objects are normally used as both the host build +and the target build. This is normally OK, since libiberty contains +only C code, and in a native configuration the results of the host +compiler and the target compiler are normally interoperable. + +Irix 6 is again an exception here, since the SGI native compiler +defaults to using the @samp{O32} ABI, and gcc defaults to using the +@samp{N32} ABI. On Irix 6, the target libraries are built in a +subdirectory even for a native configuration, avoiding this problem. + +There are currently no other libraries built for both the host and the +target, but there is no conceptual problem with adding more. + +@node Canadian Cross +@chapter Canadian Cross +@cindex canadian cross +@cindex building with a cross compiler +@cindex cross compiler, building with + +It is possible to use the GNU configure and build system to build a +program which will run on a system which is different from the system on +which the tools are built. In other words, it is possible to build +programs using a cross compiler. + +This is referred to as a @dfn{Canadian Cross}. + +@menu +* Canadian Cross Example:: Canadian Cross Example. +* Canadian Cross Concepts:: Canadian Cross Concepts. +* Build Cross Host Tools:: Build Cross Host Tools. +* Build and Host Options:: Build and Host Options. +* CCross not in Cygnus Tree:: Canadian Cross not in Cygnus Tree. +* CCross in Cygnus Tree:: Canadian Cross in Cygnus Tree. +* Supporting Canadian Cross:: Supporting Canadian Cross. +@end menu + +@node Canadian Cross Example +@section Canadian Cross Example + +Here is an example of a Canadian Cross. + +While running on a GNU/Linux, you can build a program which will run on +a Solaris system. You would use a GNU/Linux cross Solaris compiler to +build the program. + +Of course, you could not run the resulting program on your GNU/Linux +system. You would have to copy it over to a Solaris system before you +would run it. + +Of course, you could also simply build the programs on the Solaris +system in the first place. However, perhaps the Solaris system is not +available for some reason; perhaps you actually don't have one, but you +want to build the tools for somebody else to use. Or perhaps your +GNU/Linux system is much faster than your Solaris system. + +A Canadian Cross build is most frequently used when building programs to +run on a non-Unix system, such as DOS or Windows. It may be simpler to +configure and build on a Unix system than to support the configuration +machinery on a non-Unix system. + +@node Canadian Cross Concepts +@section Canadian Cross Concepts + +When building a Canadian Cross, there are at least two different systems +involved: the system on which the tools are being built, and the system +on which the tools will run. + +The system on which the tools are being built is called the @dfn{build} +system. + +The system on which the tools will run is called the host system. + +For example, if you are building a Solaris program on a GNU/Linux +system, as in the previous section, the build system would be GNU/Linux, +and the host system would be Solaris. + +It is, of course, possible to build a cross compiler using a Canadian +Cross (i.e., build a cross compiler using a cross compiler). In this +case, the system for which the resulting cross compiler generates code +is called the target system. (For a more complete discussion of host +and target systems, @pxref{Host and Target}). + +An example of building a cross compiler using a Canadian Cross would be +building a Windows cross MIPS ELF compiler on a GNU/Linux system. In +this case the build system would be GNU/Linux, the host system would be +Windows, and the target system would be MIPS ELF. + +The name Canadian Cross comes from the case when the build, host, and +target systems are all different. At the time that these issues were +all being hashed out, Canada had three national political parties. + +@node Build Cross Host Tools +@section Build Cross Host Tools + +In order to configure a program for a Canadian Cross build, you must +first build and install the set of cross tools you will use to build the +program. + +These tools will be build cross host tools. That is, they will run on +the build system, and will produce code that runs on the host system. + +It is easy to confuse the meaning of build and host here. Always +remember that the build system is where you are doing the build, and the +host system is where the resulting program will run. Therefore, you +need a build cross host compiler. + +In general, you must have a complete cross environment in order to do +the build. This normally means a cross compiler, cross assembler, and +so forth, as well as libraries and include files for the host system. + +@node Build and Host Options +@section Build and Host Options +@cindex configuring a canadian cross +@cindex canadian cross, configuring + +When you run @file{configure}, you must use both the @samp{--build} and +@samp{--host} options. + +@cindex @samp{--build} option +@cindex build option +@cindex configure build system +The @samp{--build} option is used to specify the configuration name of +the build system. This can normally be the result of running the +@file{config.guess} shell script, and it is reasonable to use +@samp{--build=`config.guess`}. + +@cindex @samp{--host} option +@cindex host option +@cindex configure host +The @samp{--host} option is used to specify the configuration name of +the host system. + +As we explained earlier, @file{config.guess} is used to set the default +value for the @samp{--host} option (@pxref{Using the Host Type}). We +can now see that since @file{config.guess} returns the type of system on +which it is run, it really identifies the build system. Since the host +system is normally the same as the build system (i.e., people do not +normally build using a cross compiler), it is reasonable to use the +result of @file{config.guess} as the default for the host system when +the @samp{--host} option is not used. + +It might seem that if the @samp{--host} option were used without the +@samp{--build} option that the configure script could run +@file{config.guess} to determine the build system, and presume a +Canadian Cross if the result of @file{config.guess} differed from the +@samp{--host} option. However, for historical reasons, some configure +scripts are routinely run using an explicit @samp{--host} option, rather +than using the default from @file{config.guess}. As noted earlier, it +is difficult or impossible to reliably compare configuration names +(@pxref{Using the Target Type}). Therefore, by convention, if the +@samp{--host} option is used, but the @samp{--build} option is not used, +then the build system defaults to the host system. + +@node CCross not in Cygnus Tree +@section Canadian Cross not in Cygnus Tree. + +If you are not using the Cygnus tree, you must explicitly specify the +cross tools which you want to use to build the program. This is done by +setting environment variables before running the @file{configure} +script. + +You must normally set at least the environment variables @samp{CC}, +@samp{AR}, and @samp{RANLIB} to the cross tools which you want to use to +build. + +For some programs, you must set additional cross tools as well, such as +@samp{AS}, @samp{LD}, or @samp{NM}. + +You would set these environment variables to the build cross tools which +you are going to use. + +For example, if you are building a Solaris program on a GNU/Linux +system, and your GNU/Linux cross Solaris compiler were named +@samp{solaris-gcc}, then you would set the environment variable +@samp{CC} to @samp{solaris-gcc}. + +@node CCross in Cygnus Tree +@section Canadian Cross in Cygnus Tree +@cindex canadian cross in cygnus tree + +This section describes configuring and building a Canadian Cross when +using the Cygnus tree. + +@menu +* Standard Cygnus CCross:: Building a Normal Program. +* Cross Cygnus CCross:: Building a Cross Program. +@end menu + +@node Standard Cygnus CCross +@subsection Building a Normal Program + +When configuring a Canadian Cross in the Cygnus tree, all the +appropriate environment variables are automatically set to +@samp{@var{host}-@var{tool}}, where @var{host} is the value used for the +@samp{--host} option, and @var{tool} is the name of the tool (e.g., +@samp{gcc}, @samp{as}, etc.). These tools must be on your @samp{PATH}. + +Adding a prefix of @var{host} will give the usual name for the build +cross host tools. To see this, consider that when these cross tools +were built, they were configured to run on the build system and to +produce code for the host system. That is, they were configured with a +@samp{--target} option that is the same as the system which we are now +calling the host. Recall that the default name for installed cross +tools uses the target system as a prefix (@pxref{Using the Target +Type}). Since that is the system which we are now calling the host, +@var{host} is the right prefix to use. + +For example, if you configure with @samp{--build=i386-linux-gnu} and +@samp{--host=solaris}, then the Cygnus tree will automatically default +to using the compiler @samp{solaris-gcc}. You must have previously +built and installed this compiler, probably by doing a build with no +@samp{--host} option and with a @samp{--target} option of +@samp{solaris}. + +@node Cross Cygnus CCross +@subsection Building a Cross Program + +There are additional considerations if you want to build a cross +compiler, rather than a native compiler, in the Cygnus tree using a +Canadian Cross. + +When you build a cross compiler using the Cygnus tree, then the target +libraries will normally be built with the newly built target compiler +(@pxref{Host and Target Libraries}). However, this will not work when +building with a Canadian Cross. This is because the newly built target +compiler will be a program which runs on the host system, and therefore +will not be able to run on the build system. + +Therefore, when building a cross compiler with the Cygnus tree, you must +first install a set of build cross target tools. These tools will be +used when building the target libraries. + +Note that this is not a requirement of a Canadian Cross in general. For +example, it would be possible to build just the host cross target tools +on the build system, to copy the tools to the host system, and to build +the target libraries on the host system. The requirement for build +cross target tools is imposed by the Cygnus tree, which expects to be +able to build both host programs and target libraries in a single +@samp{configure}/@samp{make} step. Because it builds these in a single +step, it expects to be able to build the target libraries on the build +system, which means that it must use a build cross target toolchain. + +For example, suppose you want to build a Windows cross MIPS ELF compiler +on a GNU/Linux system. You must have previously installed both a +GNU/Linux cross Windows compiler and a GNU/Linux cross MIPS ELF +compiler. + +In order to build the Windows (configuration name @samp{i386-cygwin32}) +cross MIPS ELF (configure name @samp{mips-elf}) compiler, you might +execute the following commands (long command lines are broken across +lines with a trailing backslash as a continuation character). + +@example +mkdir linux-x-cygwin32 +cd linux-x-cygwin32 +@var{srcdir}/configure --target i386-cygwin32 --prefix=@var{installdir} \ + --exec-prefix=@var{installdir}/H-i386-linux +make +make install +cd .. +mkdir linux-x-mips-elf +cd linux-x-mips-elf +@var{srcdir}/configure --target mips-elf --prefix=@var{installdir} \ + --exec-prefix=@var{installdir}/H-i386-linux +make +make install +cd .. +mkdir cygwin32-x-mips-elf +cd cygwin32-x-mips-elf +@var{srcdir}/configure --build=i386-linux-gnu --host=i386-cygwin32 \ + --target=mips-elf --prefix=@var{wininstalldir} \ + --exec-prefix=@var{wininstalldir}/H-i386-cygwin32 +make +make install +@end example + +You would then copy the contents of @var{wininstalldir} over to the +Windows machine, and run the resulting programs. + +@node Supporting Canadian Cross +@section Supporting Canadian Cross + +If you want to make it possible to build a program you are developing +using a Canadian Cross, you must take some care when writing your +configure and make rules. Simple cases will normally work correctly. +However, it is not hard to write configure and make tests which will +fail in a Canadian Cross. + +@menu +* CCross in Configure:: Supporting Canadian Cross in Configure Scripts. +* CCross in Make:: Supporting Canadian Cross in Makefiles. +@end menu + +@node CCross in Configure +@subsection Supporting Canadian Cross in Configure Scripts +@cindex canadian cross in configure + +In a @file{configure.in} file, after calling @samp{AC_PROG_CC}, you can +find out whether this is a Canadian Cross configure by examining the +shell variable @samp{cross_compiling}. In a Canadian Cross, which means +that the compiler is a cross compiler, @samp{cross_compiling} will be +@samp{yes}. In a normal configuration, @samp{cross_compiling} will be +@samp{no}. + +You ordinarily do not need to know the type of the build system in a +configure script. However, if you do need that information, you can get +it by using the macro @samp{AC_CANONICAL_SYSTEM}, the same macro that is +used to determine the target system. This macro will set the variables +@samp{build}, @samp{build_alias}, @samp{build_cpu}, @samp{build_vendor}, +and @samp{build_os}, which correspond to the similar @samp{target} and +@samp{host} variables, except that they describe the build system. + +When writing tests in @file{configure.in}, you must remember that you +want to test the host environment, not the build environment. + +Macros like @samp{AC_CHECK_FUNCS} which use the compiler will test the +host environment. That is because the tests will be done by running the +compiler, which is actually a build cross host compiler. If the +compiler can find the function, that means that the function is present +in the host environment. + +Tests like @samp{test -f /dev/ptyp0}, on the other hand, will test the +build environment. Remember that the configure script is running on the +build system, not the host system. If your configure scripts examines +files, those files will be on the build system. Whatever you determine +based on those files may or may not be the case on the host system. + +Most autoconf macros will work correctly for a Canadian Cross. The main +exception is @samp{AC_TRY_RUN}. This macro tries to compile and run a +test program. This will fail in a Canadian Cross, because the program +will be compiled for the host system, which means that it will not run +on the build system. + +The @samp{AC_TRY_RUN} macro provides an optional argument to tell the +configure script what to do in a Canadian Cross. If that argument is +not present, you will get a warning when you run @samp{autoconf}: +@smallexample +warning: AC_TRY_RUN called without default to allow cross compiling +@end smallexample +@noindent +This tells you that the resulting @file{configure} script will not work +with a Canadian Cross. + +In some cases while it may better to perform a test at configure time, +it is also possible to perform the test at run time. In such a case you +can use the cross compiling argument to @samp{AC_TRY_RUN} to tell your +program that the test could not be performed at configure time. + +There are a few other autoconf macros which will not work correctly with +a Canadian Cross: a partial list is @samp{AC_FUNC_GETPGRP}, +@samp{AC_FUNC_SETPGRP}, @samp{AC_FUNC_SETVBUF_REVERSED}, and +@samp{AC_SYS_RESTARTABLE_SYSCALLS}. The @samp{AC_CHECK_SIZEOF} macro is +generally not very useful with a Canadian Cross; it permits an optional +argument indicating the default size, but there is no way to know what +the correct default should be. + +@node CCross in Make +@subsection Supporting Canadian Cross in Makefiles. +@cindex canadian cross in makefile + +The main Canadian Cross issue in a @file{Makefile} arises when you want +to use a subsidiary program to generate code or data which you will then +include in your real program. + +If you compile this subsidiary program using @samp{$(CC)} in the usual +way, you will not be able to run it. This is because @samp{$(CC)} will +build a program for the host system, but the program is being built on +the build system. + +You must instead use a compiler for the build system, rather than the +host system. In the Cygnus tree, this make variable +@samp{$(CC_FOR_BUILD)} will hold a compiler for the build system. + +Note that you should not include @file{config.h} in a file you are +compiling with @samp{$(CC_FOR_BUILD)}. The @file{configure} script will +build @file{config.h} with information for the host system. However, +you are compiling the file using a compiler for the build system (a +native compiler). Subsidiary programs are normally simple filters which +do no user interaction, and it is normally possible to write them in a +highly portable fashion so that the absence of @file{config.h} is not +crucial. + +@cindex @samp{HOST_CC} +The gcc @file{Makefile.in} shows a complex situation in which certain +files, such as @file{rtl.c}, must be compiled into both subsidiary +programs run on the build system and into the final program. This +approach may be of interest for advanced build system hackers. Note +that the build system compiler is rather confusingly called +@samp{HOST_CC}. + +@node Cygnus Configure +@chapter Cygnus Configure +@cindex cygnus configure + +The Cygnus configure script predates autoconf. All of its interesting +features have been incorporated into autoconf. No new programs should +be written to use the Cygnus configure script. + +However, the Cygnus configure script is still used in a few places: at +the top of the Cygnus tree and in a few target libraries in the Cygnus +tree. Until those uses have been replaced with autoconf, some brief +notes are appropriate here. This is not complete documentation, but it +should be possible to use this as a guide while examining the scripts +themselves. + +@menu +* Cygnus Configure Basics:: Cygnus Configure Basics. +* Cygnus Configure in C++ Libraries:: Cygnus Configure in C++ Libraries. +@end menu + +@node Cygnus Configure Basics +@section Cygnus Configure Basics + +Cygnus configure does not use any generated files; there is no program +corresponding to @samp{autoconf}. Instead, there is a single shell +script named @samp{configure} which may be found at the top of the +Cygnus tree. This shell script was written by hand; it was not +generated by autoconf, and it is incorrect, and indeed harmful, to run +@samp{autoconf} in the top level of a Cygnus tree. + +Cygnus configure works in a particular directory by examining the file +@file{configure.in} in that directory. That file is broken into four +separate shell scripts. + +The first is the contents of @file{configure.in} up to a line that +starts with @samp{# per-host:}. This is the common part. + +The second is the rest of @file{configure.in} up to a line that starts +with @samp{# per-target:}. This is the per host part. + +The third is the rest of @file{configure.in} up to a line that starts +with @samp{# post-target:}. This is the per target part. + +The fourth is the remainder of @file{configure.in}. This is the post +target part. + +If any of these comment lines are missing, the corresponding shell +script is empty. + +Cygnus configure will first execute the common part. This must set the +shell variable @samp{srctrigger} to the name of a source file, to +confirm that Cygnus configure is looking at the right directory. This +may set the shell variables @samp{package_makefile_frag} and +@samp{package_makefile_rules_frag}. + +Cygnus configure will next set the @samp{build} and @samp{host} shell +variables, and execute the per host part. This may set the shell +variable @samp{host_makefile_frag}. + +Cygnus configure will next set the @samp{target} variable, and execute +the per target part. This may set the shell variable +@samp{target_makefile_frag}. + +Any of these scripts may set the @samp{subdirs} shell variable. This +variable is a list of subdirectories where a @file{Makefile.in} file may +be found. Cygnus configure will automatically look for a +@file{Makefile.in} file in the current directory. The @samp{subdirs} +shell variable is not normally used, and I believe that the only +directory which uses it at present is @file{newlib}. + +For each @file{Makefile.in}, Cygnus configure will automatically create +a @file{Makefile} by adding definitions for @samp{make} variables such +as @samp{host} and @samp{target}, and automatically editing the values +of @samp{make} variables such as @samp{prefix} if they are present. + +Also, if any of the @samp{makefile_frag} shell variables are set, Cygnus +configure will interpret them as file names relative to either the +working directory or the source directory, and will read the contents of +the file into the generated @file{Makefile}. The file contents will be +read in after the first line in @file{Makefile.in} which starts with +@samp{####}. + +These @file{Makefile} fragments are used to customize behaviour for a +particular host or target. They serve to select particular files to +compile, and to define particular preprocessor macros by providing +values for @samp{make} variables which are then used during compilation. +Cygnus configure, unlike autoconf, normally does not do feature tests, +and normally requires support to be added manually for each new host. + +The @file{Makefile} fragment support is similar to the autoconf +@samp{AC_SUBST_FILE} macro. + +After creating each @file{Makefile}, the post target script will be run +(i.e., it may be run several times). This script may further customize +the @file{Makefile}. When it is run, the shell variable @samp{Makefile} +will hold the name of the @file{Makefile}, including the appropriate +directory component. + +Like an autoconf generated @file{configure} script, Cygnus configure +will create a file named @file{config.status} which, when run, will +automatically recreate the configuration. The @file{config.status} file +will simply execute the Cygnus configure script again with the +appropriate arguments. + +Any of the parts of @file{configure.in} may set the shell variables +@samp{files} and @samp{links}. Cygnus configure will set up symlinks +from the names in @samp{links} to the files named in @samp{files}. This +is similar to the autoconf @samp{AC_LINK_FILES} macro. + +Finally, any of the parts of @file{configure.in} may set the shell +variable @samp{configdirs} to a set of subdirectories. If it is set, +Cygnus configure will recursively run the configure process in each +subdirectory. If the subdirectory uses Cygnus configure, it will +contain a @file{configure.in} file but no @file{configure} file, in +which case Cygnus configure will invoke itself recursively. If the +subdirectory has a @file{configure} file, Cygnus configure assumes that +it is an autoconf generated @file{configure} script, and simply invokes +it directly. + +@node Cygnus Configure in C++ Libraries +@section Cygnus Configure in C++ Libraries +@cindex @file{libstdc++} configure +@cindex @file{libio} configure +@cindex @file{libg++} configure + +The C++ library configure system, written by Per Bothner, deserves +special mention. It uses Cygnus configure, but it does feature testing +like that done by autoconf generated @file{configure} scripts. This +approach is used in the libraries @file{libio}, @file{libstdc++}, and +@file{libg++}. + +Most of the @file{Makefile} information is written out by the shell +script @file{libio/config.shared}. Each @file{configure.in} file sets +certain shell variables, and then invokes @file{config.shared} to create +two package @file{Makefile} fragments. These fragments are then +incorporated into the resulting @file{Makefile} by the Cygnus configure +script. + +The file @file{_G_config.h} is created in the @file{libio} object +directory by running the shell script @file{libio/gen-params}. This +shell script uses feature tests to define macros and typedefs in +@file{_G_config.h}. + +@node Multilibs +@chapter Multilibs +@cindex multilibs + +For some targets gcc may have different processor requirements depending +upon command line options. An obvious example is the +@samp{-msoft-float} option supported on several processors. This option +means that the floating point registers are not available, which means +that floating point operations must be done by calling an emulation +subroutine rather than by using machine instructions. + +For such options, gcc is often configured to compile target libraries +twice: once with @samp{-msoft-float} and once without. When gcc +compiles target libraries more than once, the resulting libraries are +called @dfn{multilibs}. + +Multilibs are not really part of the GNU configure and build system, but +we discuss them here since they require support in the @file{configure} +scripts and @file{Makefile}s used for target libraries. + +@menu +* Multilibs in gcc:: Multilibs in gcc. +* Multilibs in Target Libraries:: Multilibs in Target Libraries. +@end menu + +@node Multilibs in gcc +@section Multilibs in gcc + +In gcc, multilibs are defined by setting the variable +@samp{MULTILIB_OPTIONS} in the target @file{Makefile} fragment. Several +other @samp{MULTILIB} variables may also be defined there. @xref{Target +Fragment, , The Target Makefile Fragment, gcc, Using and Porting GNU +CC}. + +If you have built gcc, you can see what multilibs it uses by running it +with the @samp{-print-multi-lib} option. The output @samp{.;} means +that no multilibs are used. In general, the output is a sequence of +lines, one per multilib. The first part of each line, up to the +@samp{;}, is the name of the multilib directory. The second part is a +list of compiler options separated by @samp{@@} characters. + +Multilibs are built in a tree of directories. The top of the tree, +represented by @samp{.} in the list of multilib directories, is the +default library to use when no special compiler options are used. The +subdirectories of the tree hold versions of the library to use when +particular compiler options are used. + +@node Multilibs in Target Libraries +@section Multilibs in Target Libraries + +The target libraries in the Cygnus tree are automatically built with +multilibs. That means that each library is built multiple times. + +This default is set in the top level @file{configure.in} file, by adding +@samp{--enable-multilib} to the list of arguments passed to configure +when it is run for the target libraries (@pxref{Host and Target +Libraries}). + +Each target library uses the shell script @file{config-ml.in}, written +by Doug Evans, to prepare to build target libraries. This shell script +is invoked after the @file{Makefile} has been created by the +@file{configure} script. If multilibs are not enabled, it does nothing, +otherwise it modifies the @file{Makefile} to support multilibs. + +The @file{config-ml.in} script makes one copy of the @file{Makefile} for +each multilib in the appropriate subdirectory. When configuring in the +source directory (which is not recommended), it will build a symlink +tree of the sources in each subdirectory. + +The @file{config-ml.in} script sets several variables in the various +@file{Makefile}s. The @file{Makefile.in} must have definitions for +these variables already; @file{config-ml.in} simply changes the existing +values. The @file{Makefile} should use default values for these +variables which will do the right thing in the subdirectories. + +@table @samp +@item MULTISRCTOP +@file{config-ml.in} will set this to a sequence of @samp{../} strings, +where the number of strings is the number of multilib levels in the +source tree. The default value should be the empty string. +@item MULTIBUILDTOP +@file{config-ml.in} will set this to a sequence of @samp{../} strings, +where the number of strings is number of multilib levels in the object +directory. The default value should be the empty string. This will +differ from @samp{MULTISRCTOP} when configuring in the source tree +(which is not recommended). +@item MULTIDIRS +In the top level @file{Makefile} only, @file{config-ml.in} will set this +to the list of multilib subdirectories. The default value should be the +empty string. +@item MULTISUBDIR +@file{config-ml.in} will set this to the installed subdirectory name to +use for this subdirectory, with a leading @samp{/}. The default value +shold be the empty string. +@item MULTIDO +@itemx MULTICLEAN +In the top level @file{Makefile} only, @file{config-ml.in} will set +these variables to commands to use when doing a recursive make. These +variables should both default to the string @samp{true}, so that by +default nothing happens. +@end table + +All references to the parent of the source directory should use the +variable @samp{MULTISRCTOP}. Instead of writing @samp{$(srcdir)/..}, +you must write @samp{$(srcdir)/$(MULTISRCTOP)..}. + +Similarly, references to the parent of the object directory should use +the variable @samp{MULTIBUILDTOP}. + +In the installation target, the libraries should be installed in the +subdirectory @samp{MULTISUBDIR}. Instead of installing +@samp{$(libdir)/libfoo.a}, install +@samp{$(libdir)$(MULTISUBDIR)/libfoo.a}. + +The @file{config-ml.in} script also modifies the top level +@file{Makefile} to add @samp{multi-do} and @samp{multi-clean} targets +which are used when building multilibs. + +The default target of the @file{Makefile} should include the following +command: +@smallexample +@@$(MULTIDO) $(FLAGS_TO_PASS) DO=all multi-do +@end smallexample +@noindent +This assumes that @samp{$(FLAGS_TO_PASS)} is defined as a set of +variables to pass to a recursive invocation of @samp{make}. This will +build all the multilibs. Note that the default value of @samp{MULTIDO} +is @samp{true}, so by default this command will do nothing. It will +only do something in the top level @file{Makefile} if multilibs were +enabled. + +The @samp{install} target of the @file{Makefile} should include the +following command: +@smallexample +@@$(MULTIDO) $(FLAGS_TO_PASS) DO=install multi-do +@end smallexample + +In general, any operation, other than clean, which should be performed +on all the multilibs should use a @samp{$(MULTIDO)} line, setting the +variable @samp{DO} to the target of each recursive call to @samp{make}. + +The @samp{clean} targets (@samp{clean}, @samp{mostlyclean}, etc.) should +use @samp{$(MULTICLEAN)}. For example, the @samp{clean} target should +do this: +@smallexample +@@$(MULTICLEAN) DO=clean multi-clean +@end smallexample + +@node FAQ +@chapter Frequently Asked Questions + +@table @asis +@item Which do I run first, @samp{autoconf} or @samp{automake}? +Except when you first add autoconf or automake support to a package, you +shouldn't run either by hand. Instead, configure with the +@samp{--enable-maintainer-mode} option, and let @samp{make} take care of +it. + +@cindex undefined macros +@item @samp{autoconf} says something about undefined macros. +This means that you have macros in your @file{configure.in} which are +not defined by @samp{autoconf}. You may be using an old version of +@samp{autoconf}; try building and installing a newer one. Make sure the +newly installled @samp{autoconf} is first on your @samp{PATH}. Also, +see the next question. + +@cindex @samp{CY_GNU_GETTEXT} in @file{configure} +@cindex @samp{AM_PROG_LIBTOOL} in @file{configure} +@item My @file{configure} script has stuff like @samp{CY_GNU_GETTEXT} in it. +This means that you have macros in your @file{configure.in} which should +be defined in your @file{aclocal.m4} file, but aren't. This usually +means that @samp{aclocal} was not able to appropriate definitions of the +macros. Make sure that you have installed all the packages you need. +In particular, make sure that you have installed libtool (this is where +@samp{AM_PROG_LIBTOOL} is defined) and gettext (this is where +@samp{CY_GNU_GETTEXT} is defined, at least in the Cygnus version of +gettext). + +@cindex @file{Makefile}, garbage characters +@item My @file{Makefile} has @samp{@@} characters in it. +This may mean that you tried to use an autoconf substitution in your +@file{Makefile.in} without adding the appropriate @samp{AC_SUBST} call +to your @file{configure} script. Or it may just mean that you need to +rebuild @file{Makefile} in your build directory. To rebuild +@file{Makefile} from @file{Makefile.in}, run the shell script +@file{config.status} with no arguments. If you need to force +@file{configure} to run again, first run @samp{config.status --recheck}. +These runs are normally done automatically by @file{Makefile} targets, +but if your @file{Makefile} has gotten messed up you'll need to help +them along. + +@cindex @samp{config.status --recheck} +@item Why do I have to run both @samp{config.status --recheck} and @samp{config.status}? +Normally, you don't; they will be run automatically by @file{Makefile} +targets. If you do need to run them, use @samp{config.status --recheck} +to run the @file{configure} script again with the same arguments as the +first time you ran it. Use @samp{config.status} (with no arguments) to +regenerate all files (@file{Makefile}, @file{config.h}, etc.) based on +the results of the configure script. The two cases are separate because +it isn't always necessary to regenerate all the files after running +@samp{config.status --recheck}. The @file{Makefile} targets generated +by automake will use the environment variables @samp{CONFIG_FILES} and +@samp{CONFIG_HEADERS} to only regenerate files as they are needed. + +@item What is the Cygnus tree? +The Cygnus tree is used for various packages including gdb, the GNU +binutils, and egcs. It is also, of course, used for Cygnus releases. +It is the build system which was developed at Cygnus, using the Cygnus +configure script. It permits building many different packages with a +single configure and make. The configure scripts in the tree are being +converted to autoconf, but the general build structure remains intact. + +@item Why do I have to keep rebuilding and reinstalling the tools? +I know, it's a pain. Unfortunately, there are bugs in the tools +themselves which need to be fixed, and each time that happens everybody +who uses the tools need to reinstall new versions of them. I don't know +if there is going to be a clever fix until the tools stabilize. + +@item Why not just have a Cygnus tree @samp{make} target to update the tools? +The tools unfortunately need to be installed before they can be used. +That means that they must be built using an appropriate prefix, and it +seems unwise to assume that every configuration uses an appropriate +prefix. It might be possible to make them work in place, or it might be +possible to install them in some subdirectory; so far these approaches +have not been implemented. +@end table + +@node Index +@unnumbered Index + +@printindex cp + +@contents +@bye diff --git a/gnu/usr.bin/binutils/gas/config/te-obsd.h b/gnu/usr.bin/binutils/gas/config/te-obsd.h new file mode 100644 index 00000000000..1f3770e3120 --- /dev/null +++ b/gnu/usr.bin/binutils/gas/config/te-obsd.h @@ -0,0 +1,24 @@ +/* te-obsd.h -- OpenBSD target environment declarations. + Copyright 2003 + Free Software Foundation, Inc. + + This file is part of GAS, the GNU Assembler. + + GAS is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2, or (at your option) + any later version. + + GAS is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with GAS; see the file COPYING. If not, write to the Free + Software Foundation, 59 Temple Place - Suite 330, Boston, MA + 02111-1307, USA. */ + +#define TE_OpenBSD 1 +#define LOCAL_LABELS_FB 1 +#include "obj-format.h" diff --git a/gnu/usr.bin/binutils/ld/emulparams/elf64btsmip_obsd.sh b/gnu/usr.bin/binutils/ld/emulparams/elf64btsmip_obsd.sh new file mode 100644 index 00000000000..f34e0ececd7 --- /dev/null +++ b/gnu/usr.bin/binutils/ld/emulparams/elf64btsmip_obsd.sh @@ -0,0 +1,6 @@ +. ${srcdir}/emulparams/elf64btsmip.sh +MAXPAGESIZE=0x10000 +TEXT_START_ADDR="0x10000000" +. ${srcdir}/emulparams/elf_obsd.sh +# XXX causes GOT oflows +NO_PAD_CDTOR=y diff --git a/gnu/usr.bin/binutils/mpw-README b/gnu/usr.bin/binutils/mpw-README deleted file mode 100644 index 767140b5b26..00000000000 --- a/gnu/usr.bin/binutils/mpw-README +++ /dev/null @@ -1,376 +0,0 @@ -This is basic information about the Macintosh(tm) MPW(tm) port of the -GNU tools. The information below applies to both native and cross -compilers. - -(Please note that there are two versions of this file; "mpw-README" -is the source form, and "Read Me for MPW" is the distribution form. -"Read Me for MPW" has 8-bit chars such as \Option-d embedded in it.) - -INSTALLING GNU TOOLS - -* System Requirements - -To use these tools, you will need a Mac with a 68020 or better or else -any PowerMac, System 7.1 or later, and MPW 3.3 or 3.4. You will *not* -need any other MPW compiler unless you want to rebuild from sources, -nor even any include files, unless you are building actual Mac -applications. For PowerMac native you will need PPCLink, however; -also the executables are PowerPC-only. - -* Automated Installation - -The simplest way to install GNU tools is to run the Install script. -The script will copy things to where you want to keep them, will build -a UserStartup file with settings corresponding to where things were -copied, and offer to put that UserStartup file in your MPW folder. - -The Install script does not alter anything in the System Folder, and -it does not take any action without confirmation. - -The Install script will be at the top level of the binary -distribution, or at the top level of the object directory if -rebuilding from source. (The sources include a file called -"mpw-install" at the top level, but it is the source to the Install -script and cannot be run directly.) - -* Manual Installation - -If you don't want to run the Install script, you can do installation -manually; this section describes the steps involved. - -The GNU tools can go in any directory that is in your {Commands} list. -We generally put all the tools somewhere like {Boot}Cygnus:latest:bin, -and then add to a UserStartup file: - - set Commands "{Boot}Cygnus:latest:bin:,{Commands}" - -However, the cpp and cc1 programs of GCC are not normally stored here. -Instead, they will be in a "lib" directory that is alongside "bin", -and organized by target and version underneath, with names like - - :lib:gcc-lib:<target>:cygnus-<version>: - -If you build and install everything yourself according to the build -instructions below, then you will not have any problems. However, you -may discover that GCC seems unable to find the right cpp and cc1; -usually this will be because directory names have changed. (Even -renaming your hard disk will make this happen.) In such cases, you -have several choices. One is just to add this directory to -{Commands}, but then you will not be able to get any other cpp or cc1, -such as those used by a different target or version. Another way is -to rename your disk and directories to match the prefix used when the -tools were compiled. Finally, you can set the variable -GCC_EXEC_PREFIX to point to the library directory: - - set GCC_EXEC_PREFIX MyDisk:Stuff:lib:gcc-lib: - export GCC_EXEC_PREFIX - -You may also want to edit MPW's HEXA 128 resource. When GCC is built -using a native GCC, it is compiled to use a special stack allocator -function alloca(). While this is very efficient, it means that GCC -will need considerable stack space to run, especially when compiling -large programs with optimization turned on. You give MPW more stack -by editing the HEXA 128 resource of the MPW Shell. A value of "0008 -0000" gives 512K of stack size, which is usually sufficient. - -USING GNU TOOLS - -* Using Native PowerMac GCC - -Using a native PowerMac GCC to produce MPW tools or MacOS applications -is more complicated than just "gC foo.c", although no more complicated -than with other Mac compilers. - -To build a native PowerMac MPW tool, use this sequence, where hello.c -is the usual "hello world" program, and genericcfrg.r is the Rez file -with the code fragment resource: - -gC -I{CIncludes} -fno-builtin -Dpascal= -c -g hello.c -PPCLink hello.o -o hello \Option-d - "{PPCLibraries}"StdCRuntime.o \Option-d - "{SharedLibraries}"InterfaceLib \Option-d - "{SharedLibraries}"StdCLib \Option-d - "{PPCLibraries}"PPCToolLibs.o \Option-d - "{PPCLibraries}"PPCCRuntime.o \Option-d - "{GCCPPCLibraries}"libgcc.xcoff -rez -d APPNAME='"'hello'"' GenericCFRG.r -o hello -setfile -t 'MPST' -c 'MPS ' hello - -The same sequence works to build a MacOS application, but you set the file -type to 'APPL' and don't link in PPCToolLibs.o. For further details on -using MPW to build Mac applications, see the general MPW documentation. - -Recent versions of PPCLink have an option to generate the code -fragment resource and automatically set creator and file type; -here is what GenericCFRG.r should look like if you have an older -PPCLink or are using GNU ld: - -#include "CodeFragmentTypes.r" - -resource 'cfrg' (0) { - { - kPowerPC, - kFullLib, - kNoVersionNum,kNoVersionNum, - 0,0, - kIsApp,kOnDiskFlat,kZeroOffset,kWholeFork, - APPNAME // must be defined on Rez command line with -d option - } -}; - -In general this port of GCC supports the same option syntax and -behavior as its Unix counterpart. It also has similar compilation -rules, so it will run the assembler on .s files and so forth. - -The GCC manual includes full information on the available options. -One option that may be especially useful is "-v", which shows you what -tools and options are being used; unlike most Mac C compilers, GCC -directs assembly and linking in addition to compilation. - -MPW GCC does feature two extensions to the option syntax; '-d macro=name' -works just as '-Dmacro=name' does in Unix, and '-i directory' works the -same as '-Idirectory'. - -MPW GCC supports the usual Pascal-style strings and alignment pragmas. - -To find standard include files you can set the variable GCCIncludes: - - set GCCIncludes MyDisk:MyIncludes: - export GCCIncludes - -GCCIncludes is similar to MPW's CIncludes or CW's MWCIncludes. In -order to use MPW's usual include files, just say: - - set GCCIncludes "{CIncludes}" - export GCCIncludes - -* Using GCC as a Cross-Compiler - -If you have a cross-compiler, and you have all of the correct -target-side crt0 and libraries available, then to compile and link a -file "foo.c", you can say just - - gC foo.c - -The output file will be an MPW binary file named "a.out"; the format -of the contents will depend on which target is in use, so for instance -a MIPS-targeting GCC will produce ECOFF or ELF executables. - -Note that using MPW include files with a cross-compiler is somewhat -dangerous. - -* Using the Assembler and Friends - -The assembler ("as") and linker ("ld") are faithful ports of their -Unix counterparts. Similarly, the binutils "ar", "cplusfilt", "nm", -"objcopy", "objdump", "ranlib", "size", "strings", and "strip" are all -like they are under Unix. (Note that "cplusfilt" is usually called -"c++filt" under Unix.) - -* Using GDB - -There are two flavors of GDB. "gdb" is an MPW tool that works very -much like it does in Unix; put a command into the MPW worksheet and -type the <enter> key to send it to GDB. While "gdb" is running, you -cannot do anything else in MPW, although you can switch to other -Mac applications and use them. - -"SiowGDB" is also a Mac application, but it is GDB using the SIOW -package to provide console emulation. Commands are exactly as for the -MPW tool, but since this is its own application, you can switch -between it and MPW. - -BUILDING GNU TOOLS - -This port of the GNU tools uses a configure script similar to -that used for GNU tools under Unix, but rewritten for MPW. As with -Unix configuration, there is an "object" directory that may be -different from the "source" directory. In the example commands below, -we will assume that we are currently in the object directory, and that -the source directory is "{Boot}Cygnus:src:". - -* Requirements for Building - -In addition to the sources, you will need a set of tools that the -configure and build scripts assume to be available. These tools -(and their versions, if relevant) are as follows: - - byacc tool - flex (2.3.7) tool (and Flex.skel file) - forward-include script - MoveIfChange script - mpw-touch script - mpw-true script - NewFolderRecursive script - null-command script - open-brace script - sed (1.13) tool - tr-7to8 script - true script - -The scripts are in the sources, under utils:mpw:. You must arrange to -get the other tools yourself (they are readily available from the -"usual" net sites, and are also on many CDROMS). In addition, there -will usually be a set of these available at ftp.cygnus.com, in pub/mac. - -You may put the build tools in your usual Tools or Scripts -directories, or keep them in a separate directories. We prefer to -make a directory called "buildtools" and we put this in one of our -UserStartup files: - - set Commands "{Boot}Cygnus:buildtools:,{Commands}" - -Flex uses an environment variable FLEX_SKELETON to locate its skeleton -file, so you need to do something like this, preferably in a UserStartup: - - Set FLEX_SKELETON "{Boot}"Cygnus:buildtools:Flex.skel - Export FLEX_SKELETON - -* Configuring - -Before you can build anything, you must configure. You do this by -creating an directory where object files will be stored, setdirectory -to that directory and do a configure command: - - {Boot}Cygnus:src:mpw-configure --target <name> --cc <compiler> --srcdir {Boot}Cygnus:src: --prefix <whatever> - -If the source directory is not in your {Commands} list, then you must -supply a full pathname to mpw-configure, since mpw-configure invokes -itself after switching into each subdirectory. Using a relative -pathname, even something like ':mpw-configure', will therefore not work. - -<name> must be a known target. Valid ones include "m68k-apple-macos", -"powerpc-apple-macos", "i386-unknown-go32", "mips-idt-ecoff", and -"sh-hitachi-hms". Not all target types are accepted for all of the -tools yet. - -<compiler> must be the name of the compiler to use. It defaults to "mpwc". - - (m68k) - mpwc MPW C - sc68k Symantec C - mwc68k Metrowerks C (Codewarrior) - gcc68k GCC - - (powerpc) - ppcc PPCC - mrc Macintosh on RisC (Mister C, aka(?) Frankenstein) - scppc Symantec C - mwcppc Metrowerks C (Codewarrior) - gccppc GCC - -Not all compilers will compile all tools equally well! For m68k Macs, -MPW C has the best record so far (it has problems, but they can be -worked around), while for PowerMacs, CodeWarrior is the only compiler -that has successfully compiled everything into running code. - -<prefix> is the path that "gcc" will prepend when looking for tools -to execute. GCC_EXEC_PREFIX overrides this value, so you need not -include it if you plan to use GCC_EXEC_PREFIX. - -As an example, here is the configure line that you could use to build -native PowerMac GCC: - -"{Boot}"Cygnus:src:mpw-configure --cc mwcppc --target powerpc-apple-macos --srcdir "{Boot}"Cygnus:src: --prefix "{Boot}"GNUTools: - -* Building - -If you use CodeWarrior, you *must* first set MWCIncludes to -{CIncludes}. This is because you will be building MPW tools, and -their standard I/O works by making references to data that is part of -the MPW Shell, which means that the code must be compiled and linked -with macros that refer to that data, and those macros are in -{CIncludes}, not the default {MWCIncludes}. Without this change, you -will encounter problems compiling libiberty/mpw.c, but tweaking that -file only masks the real problem, and does not fix it. - -The command - - mpw-build - -will build everything. Building will take over an hour on a Quadra 800 -or PowerMac 8100/110, longer if the sources are on a shared volume. - -You may see some warnings; these are mostly likely benign, typically -disagreements about declarations of library and system functions. - -* Installing - -To install the just-built tools, use the command - - mpw-build install - -This part of the installation procedure just copies files to the -location specified at configure time by <prefix>, and, in some cases, -renames them from temporary internal names to their usual names. This -install process is *not* the same as what the Install script does; -Install can copy tools from the installation location chosen at -configuration time to a user-chosen place, and sets up a UserStartup -file. Note that while the Install script is optional, the install -build action performs some tasks would be very hard to replicate -manually, so you should always do it before using the tools. - -* Known Problems With Using Various Compilers to Build - -Most versions of MPW C have problems with compiling GNU software. - -MPW C 3.2.x has preprocessing bugs that render it incapable of -compiling the BFD library, so it can't be used at all for building BFD. - -MPW C 3.3, 3.3.1, and 3.3.2 will spontaneously claim to have found -errors in the source code, but in fact the code is perfectly fine. If -this happens, just set the working directory back to the top-level -objdir (where the configure command above was performed), and type -"mpw-build all" again. If it goes on through the supposed error, then -you got one of the spurious errors. A full build may require a number -of these restarts. - -MPW C 3.3.3 seems to work OK, at least with the aid of a number of -workarounds that are in the sources (look for #ifdef MPW_C). - -Versions of MPW Make earlier than 4.0d2 have exhibited bizarre behavior, -failure to substitute variables and the like. - -Metrowerks CW6 PPC linker (MWLinkPPC) seems to do bad things with memory -if the "Modern Memory Manager" is turned on (in the Memory control panel), -but works OK if it is turned off. - -Metrowerks CW6 loses bigtime compiling opcodes:ppc-opc.c, which has -some deeply nested macros. (CW7 is OK.) There is a way to patch the -file, by substituting constant values. If you need to do this, -contact shebs@cygnus.com for details. - -<Gestalt.h> is missing from {CIncludes} in the MPW version that comes -with CW7. You can just copy the one in CW7's {MWCIncludes}. - -CW8 and later have changes to headers and such that will require changes -to the source in order to be able to use them to rebuild. - -KNOWN BUGS - -The declarations for memcpy and memcmp in some versions of header files -may conflict with GCC's builtin definition. Either use -fno-builtin -or ignore the warnings. - -This is not a bug, but - watch out for cr/nl translation! For instance, -if config/mpw-mh-mpw is not properly translated because it has been -copied or updated separately, then everything will almost build, but -you will get puzzling error messages from make or the compiler. - -'/' or ' ' embedded in any device, directory, or file name may or may -not work. - -objcopy -O srec foo.o makes random output filenames. - -Mac-x-mips requires -mgas but Unix hosts don't. - -GDB will frequently require a '/' on the front of a device name in order -to recognize it as an absolute rather than a relative pathname. - -GDB doesn't seem to use the printer port correctly, although it tries. - -The cursor doesn't always spin as much as it should. To get elaborate -statistics and warnings about spin rates, add this to UserStartup: - - set MEASURE_SPIN all - export MEASURE_SPIN diff --git a/gnu/usr.bin/binutils/mpw-build.in b/gnu/usr.bin/binutils/mpw-build.in deleted file mode 100644 index 86d9530fa3b..00000000000 --- a/gnu/usr.bin/binutils/mpw-build.in +++ /dev/null @@ -1,204 +0,0 @@ -# Top-level script fragment to build everything for MPW. - -Set savedir "`Directory`" - -#Set Echo 1 - -Set ThisScript "{0}" - -Set objdir ":" - -Set verify 0 - -Set BuildTarget "none" - -# Parse arguments. - -Loop - Break If {#} == 0 - If "{BuildTarget}" =~ /none/ - Set BuildTarget "{1}" - Else - Echo Only one build target allowed, ignoring "{1}" - End If - Shift 1 -End Loop - -If "{BuildTarget}" =~ /none/ - Set BuildTarget "all" -End If - -If {verify} == 1 - Echo "#" Doing "{ThisScript}" "{BuildTarget}" in "`Directory`" ... -End If - -Set ranmake 0 - -If "`Exists Makefile`" != "" - Echo "Set Echo 1" >{BuildTarget}.makeout - Make -f Makefile {BuildTarget} >>{BuildTarget}.makeout - {BuildTarget}.makeout - Delete {BuildTarget}.makeout - Set ranmake 1 -End If - -If "`Exists Makefile.PPC`" != "" - Echo "Set Echo 1" >{BuildTarget}.makeout.ppc - Make -f Makefile.PPC {BuildTarget} >>{BuildTarget}.makeout.ppc - {BuildTarget}.makeout.ppc - Delete {BuildTarget}.makeout.ppc - Set ranmake 1 -End If - -If {ranmake} == 1 - Exit -End If - -# Dispatch on various pseudo-targets. - -If "{BuildTarget}" =~ /all/ - Echo Started `Date` - "{ThisScript}" all-gcc - "{ThisScript}" all-gdb - Echo Finished `Date` -Else If "{BuildTarget}" =~ /all-libiberty/ - "{ThisScript}" do-libiberty -Else If "{BuildTarget}" =~ /all-bfd/ - "{ThisScript}" do-bfd -Else If "{BuildTarget}" =~ /all-opcodes/ - "{ThisScript}" do-opcodes -Else If "{BuildTarget}" =~ /all-byacc/ - "{ThisScript}" do-byacc -Else If "{BuildTarget}" =~ /all-flex/ - "{ThisScript}" all-libiberty - "{ThisScript}" do-flex -Else If "{BuildTarget}" =~ /all-binutils/ - "{ThisScript}" all-libiberty - "{ThisScript}" all-bfd - "{ThisScript}" all-opcodes - "{ThisScript}" do-binutils -Else If "{BuildTarget}" =~ /all-gas/ - "{ThisScript}" all-libiberty - "{ThisScript}" all-bfd - "{ThisScript}" all-opcodes - "{ThisScript}" do-gas -Else If "{BuildTarget}" =~ /all-gcc/ - "{ThisScript}" all-libiberty - "{ThisScript}" all-gas - "{ThisScript}" all-binutils - "{ThisScript}" all-ld - "{ThisScript}" do-gcc -Else If "{BuildTarget}" =~ /all-gdb/ - "{ThisScript}" all-libiberty - "{ThisScript}" all-bfd - "{ThisScript}" all-opcodes - "{ThisScript}" do-gdb -Else If "{BuildTarget}" =~ /all-grez/ - "{ThisScript}" all-libiberty - "{ThisScript}" all-bfd - "{ThisScript}" do-grez -Else If "{BuildTarget}" =~ /all-ld/ - "{ThisScript}" all-libiberty - "{ThisScript}" all-bfd - "{ThisScript}" all-opcodes - "{ThisScript}" do-ld -Else If "{BuildTarget}" =~ /do-byacc/ - SetDirectory :byacc: - ::mpw-build all -Else If "{BuildTarget}" =~ /do-flex/ - SetDirectory :flex: - ::mpw-build _bootstrap - ::mpw-build all -Else If "{BuildTarget}" =~ /do-bfd/ - SetDirectory :bfd: - ::mpw-build all -Else If "{BuildTarget}" =~ /do-libiberty/ - SetDirectory :libiberty: - ::mpw-build all -Else If "{BuildTarget}" =~ /do-opcodes/ - SetDirectory :opcodes: - ::mpw-build all -Else If "{BuildTarget}" =~ /do-binutils/ - SetDirectory :binutils: - ::mpw-build stamps - ::mpw-build all -Else If "{BuildTarget}" =~ /do-gas/ - SetDirectory :gas: - ::mpw-build stamps - ::mpw-build all -Else If "{BuildTarget}" =~ /do-gcc/ - SetDirectory :gcc: - :mpw-build all -Else If "{BuildTarget}" =~ /do-gdb/ - SetDirectory :gdb: - ::mpw-build all -Else If "{BuildTarget}" =~ /do-grez/ - SetDirectory :grez: - ::mpw-build all -Else If "{BuildTarget}" =~ /do-ld/ - SetDirectory :ld: - ::mpw-build all -Else If "{BuildTarget}" =~ /do-newlib/ - SetDirectory :newlib: - ::mpw-build all -Else If "{BuildTarget}" =~ /install/ - "{ThisScript}" install-only-top - "{ThisScript}" install-binutils - "{ThisScript}" install-gas - "{ThisScript}" install-gcc - "{ThisScript}" install-ld - "{ThisScript}" install-gdb -Else If "{BuildTarget}" =~ /install-binutils/ - SetDirectory :binutils: - ::mpw-build install -Else If "{BuildTarget}" =~ /install-gas/ - SetDirectory :gas: - ::mpw-build install -Else If "{BuildTarget}" =~ /install-gcc/ - SetDirectory :gcc: - :mpw-build install -Else If "{BuildTarget}" =~ /install-gdb/ - SetDirectory :gdb: - ::mpw-build install -Else If "{BuildTarget}" =~ /install-grez/ - SetDirectory :grez: - ::mpw-build install -Else If "{BuildTarget}" =~ /install-ld/ - SetDirectory :ld: - ::mpw-build install -Else If "{BuildTarget}" =~ /install-only/ - "{ThisScript}" install-only-top - "{ThisScript}" install-only-binutils - "{ThisScript}" install-only-gas - "{ThisScript}" install-only-gcc - "{ThisScript}" install-only-gdb - "{ThisScript}" install-only-ld -Else If "{BuildTarget}" =~ /install-only-binutils/ - SetDirectory :binutils: - ::mpw-build install-only -Else If "{BuildTarget}" =~ /install-only-gas/ - SetDirectory :gas: - ::mpw-build install-only -Else If "{BuildTarget}" =~ /install-only-gcc/ - SetDirectory :gcc: - :mpw-build install-only -Else If "{BuildTarget}" =~ /install-only-gdb/ - SetDirectory :gdb: - ::mpw-build install-only -Else If "{BuildTarget}" =~ /install-only-grez/ - SetDirectory :grez: - ::mpw-build install-only -Else If "{BuildTarget}" =~ /install-only-ld/ - SetDirectory :ld: - ::mpw-build install-only -Else If "{BuildTarget}" =~ /install-only-top/ - NewFolderRecursive "{prefix}" - If "{prefix}" != "`Directory`" - Duplicate -y 'Read Me for MPW' "{prefix}"'Read Me for MPW' - Duplicate -y Install "{prefix}"Install - End If -Else - Echo {BuildTarget} not understood, ignoring -End If - -SetDirectory "{savedir}" diff --git a/gnu/usr.bin/binutils/mpw-config.in b/gnu/usr.bin/binutils/mpw-config.in deleted file mode 100644 index 8028737a8b6..00000000000 --- a/gnu/usr.bin/binutils/mpw-config.in +++ /dev/null @@ -1,113 +0,0 @@ -# Configuration fragment for Cygnus source tree. - -# Check that we can find all the special tools that we will need. -# The test for sed is semi-pointless, because it's already been invoked -# by the calculation of target_cpu in the main configure script, but -# the test will also show which one is being used. - -Set Exit 0 -Echo byacc is `Which byacc` -Echo flex is `Which flex` -Echo forward-include is `Which forward-include` -Echo MoveIfChange is `Which MoveIfChange` -Echo mpw-touch is `Which mpw-touch` -Echo mpw-true is `Which mpw-true` -Echo NewFolderRecursive is `Which NewFolderRecursive` -Echo null-command is `Which null-command` -Echo open-brace is `Which open-brace` -Echo sed is `Which sed` -Echo 'tr-7to8' is `Which tr-7to8` -Echo true is `Which true` -Set Exit 1 - -Set host_libs "mmalloc libiberty opcodes bfd readline gash tcl tk tclX" - -Set host_tools "texinfo byacc flex bison binutils ld gas gcc gdb make patch \Option-d - prms send-pr gprof gdbtest tgas etc expect dejagnu sim bash \Option-d - m4 autoconf ispell grep diff rcs cvs fileutils shellutils time \Option-d - textutils wdiff find emacs emacs19 uudecode hello tar gzip indent \Option-d - recode release sed utils guile perl apache inet gawk" - -Set target_libs "newlib" - -Set target_tools "examples" - -# Configure the resource compiler if targeting Macs. -If {target_os} =~ /macos/ || {target_os} =~ /mpw/ - Set host_tools "{host_tools} grez" -End If - -Set configdirs "{host_libs} {host_tools} {target_libs} {target_tools}" -Export configdirs - -# Make up a special include directory that tools will share. - -If "`Exists "{objdir}"extra-include`" == "" - NewFolder "{objdir}"extra-include -End If - -Set edir "{objdir}extra-include:" - -forward-include "{srcdir}"include:mpw:sys:file.h "{edir}"'sys/file.h' -forward-include "{srcdir}"include:mpw:sys:ioctl.h "{edir}"'sys/ioctl.h' -forward-include "{srcdir}"include:mpw:sys:param.h "{edir}"'sys/param.h' -forward-include "{srcdir}"include:mpw:sys:resource.h "{edir}"'sys/resource.h' -forward-include "{srcdir}"include:mpw:sys:stat.h "{edir}"'sys/stat.h' -forward-include "{srcdir}"include:mpw:sys:time.h "{edir}"'sys/time.h' -forward-include "{srcdir}"include:mpw:sys:types.h "{edir}"'sys/types.h' - -forward-include "{srcroot}"include:aout:aout64.h "{edir}"'aout/aout64.h' -forward-include "{srcroot}"include:aout:ar.h "{edir}"'aout/ar.h' -forward-include "{srcroot}"include:aout:ranlib.h "{edir}"'aout/ranlib.h' -forward-include "{srcroot}"include:aout:reloc.h "{edir}"'aout/reloc.h' -forward-include "{srcroot}"include:aout:stab.def "{edir}"'aout/stab.def' -forward-include "{srcroot}"include:aout:stab_gnu.h "{edir}"'aout/stab_gnu.h' - -If "`Exists "{srcroot}"include:aout:"{target_cpu}".h`" != "" - forward-include "{srcroot}"include:aout:"{target_cpu}".h "{edir}"'aout/'"{target_cpu}"'.h' -End If - -forward-include "{srcroot}"include:coff:ecoff.h "{edir}"'coff/ecoff.h' -forward-include "{srcroot}"include:coff:internal.h "{edir}"'coff/internal.h' -forward-include "{srcroot}"include:coff:sym.h "{edir}"'coff/sym.h' -forward-include "{srcroot}"include:coff:symconst.h "{edir}"'coff/symconst.h' - -If "`Exists "{srcroot}"include:coff:"{target_cpu}".h`" != "" - forward-include "{srcroot}"include:coff:"{target_cpu}".h "{edir}"'coff/'"{target_cpu}"'.h' -End If -If "{target_cpu}" =~ /powerpc/ - forward-include "{srcroot}"include:coff:rs6000.h "{edir}"'coff/rs6000.h' -End If - -forward-include "{srcroot}"include:elf:common.h "{edir}"'elf/common.h' -forward-include "{srcroot}"include:elf:dwarf.h "{edir}"'elf/dwarf.h' -forward-include "{srcroot}"include:elf:dwarf2.h "{edir}"'elf/dwarf2.h' -forward-include "{srcroot}"include:elf:external.h "{edir}"'elf/external.h' -forward-include "{srcroot}"include:elf:internal.h "{edir}"'elf/internal.h' - -# Believe it or not, GDB needs this for all targets. -forward-include "{srcroot}"include:elf:mips.h "{edir}"'elf/mips.h' - -If "`Exists "{srcroot}"include:elf:"{target_cpu}".h`" != "" - forward-include "{srcroot}"include:elf:"{target_cpu}".h "{edir}"'elf/'"{target_cpu}"'.h' -End If -If "{target_cpu}" =~ /powerpc/ - forward-include "{srcroot}"include:elf:ppc.h "{edir}"'elf/ppc.h' -End If - -If "`Exists "{srcroot}"include:opcode:"{target_cpu}".h`" != "" - forward-include "{srcroot}"include:opcode:"{target_cpu}".h "{edir}"'opcode/'"{target_cpu}"'.h' -End If -If "{target_cpu}" =~ /powerpc/ - forward-include "{srcroot}"include:opcode:ppc.h "{edir}"'opcode/ppc.h' -End If - -# Add some bfd includes that get mentioned outside the bfd dir. - -forward-include "{srcroot}"bfd:libcoff.h "{edir}"'bfd/libcoff.h' -forward-include "{srcroot}"bfd:libecoff.h "{edir}"'bfd/libecoff.h' - -# Translate random files into MPW-only character set. - -tr-7to8 "{srcdir}"mpw-README > "{objdir}Read Me for MPW" -tr-7to8 "{srcdir}"mpw-install > "{objdir}"Install diff --git a/gnu/usr.bin/binutils/mpw-configure b/gnu/usr.bin/binutils/mpw-configure deleted file mode 100644 index cf45148ec63..00000000000 --- a/gnu/usr.bin/binutils/mpw-configure +++ /dev/null @@ -1,448 +0,0 @@ -# Configuration script -# Copyright (C) 1994, 1995, 1996 Free Software Foundation, Inc. - -# This program is free software; you can redistribute it and/or modify -# it under the terms of the GNU General Public License as published by -# the Free Software Foundation; either version 2 of the License, or -# (at your option) any later version. -# -# This program is distributed in the hope that it will be useful, -# but WITHOUT ANY WARRANTY; without even the implied warranty of -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -# GNU General Public License for more details. -# -# You should have received a copy of the GNU General Public License -# along with this program; if not, write to the Free Software -# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. - -### WARNING -### This script must NOT use any 8-bit chars! -### WARNING - -# This is an MPW Shell script that sets everything up for compilation, -# mainly creating directories, and editing copies of files. - -Set savedir "`Directory`" - -#Set Echo 1 - -Set ThisScript "{0}" - -Set srcroot "--------" - -Set srcdir ":" - -Set objdir ":" - -Set prefix "{MPW}":GNUTools: - -Set exec_prefix "" - -Set bindir "" - -Set host_alias "m68k-apple-mpw" - -Set target_alias {host_alias} - -Set host_cc "mpwc" - -Set with_gnu_ld 0 - -Set helpoutput 0 - -Set recurse 1 - -Set verify 0 -Set verifystr "" - -Set enable_options "" -Set disable_options "" - -# Parse arguments. - -Loop - Break If {#} == 0 - If "{1}" =~ /--cc/ - Set host_cc "{2}" - Shift 1 - Else If "{1}" =~ /--bindir/ - Set bindir "{2}" - Shift 1 - Else If "{1}" =~ /--disable-?+/ - Set `Echo {1} | sed -e 's/--disable-/enable_/'` no - Set disable_options "{disable_options} '{1}'" - Else If "{1}" =~ /--enable-?+/ - Set `Echo {1} | sed -e 's/--enable-/enable_/'` yes - Set enable_options "{enable_options} '{1}'" - Else If "{1}" =~ /--exec-prefix/ - Set exec_prefix "{2}" - Shift 1 - Else If "{1}" =~ /--help/ - Set helpoutput 1 - Else If "{1}" =~ /--host/ - Set host_alias "{2}" - Shift 1 - Else If "{1}" =~ /--norecursion/ - Set recurse 0 - Else If "{1}" =~ /--prefix/ - Set prefix "{2}" - Shift 1 - Else If "{1}" =~ /--srcdir/ - Set srcdir "{2}" - Shift 1 - Else If "{1}" =~ /--srcroot/ - Set srcroot "{2}" - Shift 1 - Else If "{1}" =~ /--target/ - Set target_alias "{2}" - Shift 1 - Else If "{1}" =~ /-v/ - Set verify 1 - Set verifystr "-v" - Else If "{1}" =~ /--with-gnu-ld/ - Set with_gnu_ld 1 - Else - Echo -n 'mpw-configure: Unrecognized option: "' - Echo -n "{1}" - Echo '"; use --help for usage.' - Exit 1 - End If - Shift 1 -End Loop - -If {helpoutput} == 1 - Echo "Usage: mpw-configure [OPTIONS]" - Echo "" - Echo "Options: [defaults in brackets]" - Echo "--bindir DIR directory for binaries []" - Echo "--cc CC use C compiler CC [mpwc]" - Echo "--disable-FOO do not include feature FOO" - Echo "--enable-FOO include feature FOO" - Echo "--exec-prefix DIR install host-dependent files into DIR []" - Echo "--help print this message" - Echo "--host HOST configure for HOST [m68k-apple-mpw]" - Echo "--norecursion configure this directory only [recurse]" - Echo "--prefix DIR install into DIR [{MPW}:GNUTools:]" - Echo "--srcdir DIR find the sources in DIR [:]" - Echo "--srcroot DIR find the toplevel sources in DIR [:]" - Echo "--target TARGET configure for TARGET [TARGET=HOST]" - Echo "-v verbose" - Echo "--with-gnu-ld link using GNU ld [no]" - Exit 0 -End If - -Set Exit 0 - -# Default exec_prefix from prefix. - -If "{exec_prefix}" == "" - Set exec_prefix "{prefix}" -End If - -If "{bindir}" == "" - Set bindir "{prefix}"bin: -End If - -# Point to the correct set of tools to use with the chosen compiler. - -If "{host_cc}" =~ /mpwc/ - Set host_alias "m68k-apple-mpw" - Set cc_name '{CC_MPW_C}' - Set segment_flag '-s ' - Set ar_name '{AR_LIB}' - Set ranlib_name '{RANLIB_NULL}' - Set cc_ld_name '{CC_LD_LINK}' - Set prog_ext_name '{PROG_EXT_68K}' - Set extralibs_name '{EXTRALIBS_C}' - Set makepef_name '{MAKEPEF_NULL}' - Set rez_name '{REZ_68K}' -Else If "{host_cc}" =~ /sc68k/ - Set host_alias "m68k-apple-mpw" - Set cc_name '{CC_SC}' - Set segment_flag '-s ' - Set ar_name '{AR_LIB}' - Set ranlib_name '{RANLIB_NULL}' - Set cc_ld_name '{CC_LD_LINK}' - Set prog_ext_name '{PROG_EXT_68K}' - Set extralibs_name '{EXTRALIBS_C}' - Set makepef_name '{MAKEPEF_NULL}' - Set rez_name '{REZ_68K}' -Else If "{host_cc}" =~ /mwc68k/ - Set host_alias "m68k-apple-mpw" - Set cc_name '{CC_MWC68K}' - Set segment_flag '-s ' - Set ar_name '{AR_MWLINK68K}' - Set ranlib_name '{RANLIB_NULL}' - Set cc_ld_name '{CC_LD_MWLINK68K}' - Set prog_ext_name '{PROG_EXT_68K}' - Set extralibs_name '{EXTRALIBS_MWC68K}' - Set makepef_name '{MAKEPEF_NULL}' - Set rez_name '{REZ_68K}' -Else If "{host_cc}" =~ /gcc68k/ - Set host_alias "m68k-apple-mpw" - Set cc_name '{CC_68K_GCC}' - Set segment_flag '-s ' - Set ar_name '{AR_68K_AR}' - Set ranlib_name '{RANLIB_RANLIB}' - Set cc_ld_name '{CC_68K_GCC}' - Set prog_ext_name '{PROG_EXT_68K}' - Set extralibs_name '{EXTRALIBS_C}' - Set makepef_name '{MAKEPEF_NULL}' - Set rez_name '{REZ_68K}' -Else If "{host_cc}" =~ /ppcc/ - Set host_alias "powerpc-apple-mpw" - Set cc_name '{CC_PPCC}' - Set segment_flag '-d ___s_e_g___=' - Set ar_name '{AR_PPCLINK}' - Set ranlib_name '{RANLIB_NULL}' - Set cc_ld_name '{CC_LD_PPCLINK}' - Set prog_ext_name '{PROG_EXT_XCOFF}' - Set extralibs_name '{EXTRALIBS_PPC}' - Set makepef_name '{MAKEPEF_PPC}' - Set rez_name '{REZ_PPC}' -Else If "{host_cc}" =~ /mrc/ - Set host_alias "powerpc-apple-mpw" - Set cc_name '{CC_MRC}' - Set segment_flag '-d ___s_e_g___=' - Set ar_name '{AR_PPCLINK}' - Set ranlib_name '{RANLIB_NULL}' - Set cc_ld_name '{CC_LD_PPCLINK}' - Set prog_ext_name '{PROG_EXT_XCOFF}' - Set extralibs_name '{EXTRALIBS_PPC}' - Set makepef_name '{MAKEPEF_PPC}' - Set rez_name '{REZ_PPC}' -Else If "{host_cc}" =~ /scppc/ - Set host_alias "powerpc-apple-mpw" - Set cc_name '{CC_SC}' - Set segment_flag '-d ___s_e_g___=' - Set ar_name '{AR_PPCLINK}' - Set ranlib_name '{RANLIB_NULL}' - Set cc_ld_name '{CC_LD_PPCLINK}' - Set prog_ext_name '{PROG_EXT_XCOFF}' - Set extralibs_name '{EXTRALIBS_PPC}' - Set makepef_name '{MAKEPEF_PPC}' - Set rez_name '{REZ_PPC}' -Else If "{host_cc}" =~ /mwcppc/ - Set host_alias "powerpc-apple-mpw" - Set cc_name '{CC_MWCPPC}' - Set segment_flag '-d ___s_e_g___=' - Set ar_name '{AR_MWLINKPPC}' - Set ranlib_name '{RANLIB_NULL}' - Set cc_ld_name '{CC_LD_MWLINKPPC}' - # Misleading, but we don't need a PEF step. - Set prog_ext_name '{PROG_EXT_68K}' - Set extralibs_name '{EXTRALIBS_MWCPPC}' - Set makepef_name '{MAKEPEF_NULL}' - Set rez_name '{REZ_PPC}' -Else If "{host_cc}" =~ /gccppc/ - Set host_alias "powerpc-apple-mpw" - Set cc_name '{CC_PPC_GCC}' - Set segment_flag '-d ___s_e_g___=' - Set ar_name '{AR_PPCLINK}' - If {with_gnu_ld} == 1 - Set ranlib_name '{RANLIB_RANLIB}' - Set cc_ld_name '{CC_LD_GLD}' - Else - Set ranlib_name '{RANLIB_NULL}' - Set cc_ld_name '{CC_LD_PPCLINK}' - End If - Set prog_ext_name '{PROG_EXT_XCOFF}' - Set extralibs_name '{EXTRALIBS_PPC}' - Set makepef_name '{MAKEPEF_PPC}' - Set rez_name '{REZ_PPC}' -Else - Echo "{host_cc}" is not a known MPW compiler type -End If - -Set dash_c_flag '' -If "{host_cc}" =~ /gcc68k/ - Set dash_c_flag '-c' -Else If "{host_cc}" =~ /gccppc/ - Set dash_c_flag '-c' -End If - -# (should interpret aliases if not in canonical form) - -Set host_canonical "{host_alias}" - -Set target_canonical "{target_alias}" - -Set configdirs "" - -If "{srcroot}" =~ /--------/ - Set srcroot "{srcdir}" -End If -If "`Exists "{srcdir}"`" == "" - Echo Source directory {srcdir} does not exist! - Exit 1 -End If -If "`Exists "{srcroot}"`" == "" - Echo Top-level source directory {srcroot} does not exist! - Exit 1 -End If - -Set target_cpu "`echo {target_canonical} | sed 's/^\(.*\)-\(.*\)-\(.*\)$/\1/'`" -Set target_vendor "`echo {target_canonical} | sed 's/^\(.*\)-\(.*\)-\(.*\)$/\2/'`" -Set target_os "`echo {target_canonical} | sed 's/^\(.*\)-\(.*\)-\(.*\)$/\3/'`" - -# Create a file that is guaranteed to be older than any other here. - -If "`Exists "{objdir}"_oldest`" == "" - mpw-touch _oldest -End If - -# Record this before creating any files, makefiles sometimes mention -# dependencies on config.status. - -Echo "# This directory was configured as follows:" >config.new -Echo "{ThisScript} --host {host_alias} --target {target_alias} --srcdir {srcdir} --srcroot {srcroot} --prefix {prefix} --cc {host_cc} {verifystr} {enable_options} {disable_options} --norecursion" >>config.new -MoveIfChange config.new config.status - -If "`Exists "{srcdir}"mpw-config.in`" != "" - tr-7to8 "{srcdir}"mpw-config.in >"{objdir}"mpw-config.in - Execute "{objdir}"mpw-config.in -End If - -# Start Makefile construction by defining all the variables chosen by -# configuration. - -Echo "# This Makefile produced by mpw-configure. Changes may get lost!" > "{objdir}"Makefile.tem -Echo "srcroot = " {srcroot} >> "{objdir}"Makefile.tem -Echo "topsrcdir = " {srcroot} >> "{objdir}"Makefile.tem -Echo "srcdir = " {srcdir} >> "{objdir}"Makefile.tem -Echo "mpw_prefix = " {prefix} >> "{objdir}"Makefile.tem -Echo "mpw_exec_prefix = " {exec_prefix} >> "{objdir}"Makefile.tem -Echo "mpw_bindir = " {bindir} >> "{objdir}"Makefile.tem -Echo "host_alias = " {host_alias} >> "{objdir}"Makefile.tem -Echo "target_alias = " {target_alias} >> "{objdir}"Makefile.tem -Echo "target_cpu = " {target_cpu} >> "{objdir}"Makefile.tem -Echo "target_vendor = " {target_vendor} >> "{objdir}"Makefile.tem -Echo "target_os = " {target_os} >> "{objdir}"Makefile.tem -Echo "target_canonical = " {target_canonical} >> "{objdir}"Makefile.tem -Echo "host_makefile_frag = " >> "{objdir}"Makefile.tem -Echo "target_makefile_frag = " >> "{objdir}"Makefile.tem -Echo "CC = " {cc_name} >> "{objdir}"Makefile.tem -Echo "AR = " {ar_name} >> "{objdir}"Makefile.tem -Echo "RANLIB = " {ranlib_name} >> "{objdir}"Makefile.tem -Echo "CC_LD = " {cc_ld_name} >> "{objdir}"Makefile.tem -Echo "PROG_EXT = " {prog_ext_name} >> "{objdir}"Makefile.tem -Echo "EXTRALIBS = " {extralibs_name} >> "{objdir}"Makefile.tem -Echo "MAKEPEF = " {makepef_name} >> "{objdir}"Makefile.tem -Echo "REZ = " {rez_name} >> "{objdir}"Makefile.tem - -If {host_cc} =~ /gccppc/ - Echo -n "dq =\Option-d\Option-d\Option-d" > "{objdir}"Makefile.tem0 - Echo '"' >> "{objdir}"Makefile.tem0 - tr-7to8 "{objdir}"Makefile.tem0 >>"{objdir}"Makefile.tem -Else - Echo -n "dq ='" >> "{objdir}"Makefile.tem - Echo -n '"' >> "{objdir}"Makefile.tem - Echo "'" >> "{objdir}"Makefile.tem -End If - -# Append the master set of definitions for the various compilers. - -If "`Exists "{srcdir}"config:mpw-mh-mpw`" != "" - tr-7to8 "{srcdir}"config:mpw-mh-mpw >>"{objdir}"Makefile.tem -Else If "`Exists "{srcroot}"config:mpw-mh-mpw`" != "" - tr-7to8 "{srcroot}"config:mpw-mh-mpw >>"{objdir}"Makefile.tem -Else - Echo "can't find a host config file!" - Exit 0 -End If - -# Append anything produced by the directory's mpw-config.in. - -If "`Exists "{objdir}"mk.tmp`" != "" - Catenate "{objdir}"mk.tmp >>"{objdir}"Makefile.tem - # An mpw-config.in might change so as not to create this - # anymore, so get rid of it now to be safe. - Delete -i -y "{objdir}"mk.tmp -End If - -# If there are sed scripts to edit the Unix Makefile.in, use them; otherwise -# use an mpw-make.in if present. - -If "`Exists "{srcdir}"mpw-make.sed`" != "" - If "`Exists "{objdir}"hacked_Makefile.in`" != "" - Set MakefileIn "{objdir}"hacked_Makefile.in - Else - Set MakefileIn "{srcdir}"Makefile.in - End If - # Find the generic makefile editing script. - If "`Exists "{srcroot}"config:mpw:g-mpw-make.sed`" != "" - sed -f "{srcroot}"config:mpw:g-mpw-make.sed "{MakefileIn}" >"{objdir}"Makefile.tem1 - Else If "`Exists "{srcroot}"utils:mpw:g-mpw-make.sed`" != "" - sed -f "{srcroot}"utils:mpw:g-mpw-make.sed "{MakefileIn}" >"{objdir}"Makefile.tem1 - Else If "`Exists "{srcdir}"g-mpw-make.sed`" != "" - sed -f "{srcdir}"g-mpw-make.sed "{MakefileIn}" >"{objdir}"Makefile.tem1 - Else - Echo Warning: g-mpw-make.sed not found, copying "{MakefileIn}" verbatim... - Catenate "{MakefileIn}" >"{objdir}"Makefile.tem1 - End If - sed -f "{srcdir}"mpw-make.sed "{objdir}"Makefile.tem1 >"{objdir}"Makefile.tem2 - sed -e 's/^prefix = .*$/prefix = {mpw_prefix}/g' -e 's/^exec_prefix = .*$/exec_prefix = {mpw_exec_prefix}/g' -e 's/^bindir = @bindir@/bindir = {mpw_bindir}/g' "{objdir}"Makefile.tem2 >"{objdir}"Makefile.tem3 - sed -e "s/@DASH_C_FLAG@/{dash_c_flag}/" -e "s/@SEGMENT_FLAG(\([^)]*\))@/{segment_flag}\1/" "{objdir}"Makefile.tem3 >"{objdir}"mpw-make.in - tr-7to8 "{objdir}"mpw-make.in >>"{objdir}"Makefile.tem - If "`Exists "{objdir}"mk.sed`" != "" - sed -f "{objdir}"mk.sed "{objdir}"Makefile.tem >"{objdir}"Makefile.tem2 - Rename -y "{objdir}"Makefile.tem2 "{objdir}"Makefile.tem - End If - MoveIfChange "{objdir}"Makefile.tem "{objdir}"Makefile - Delete -i -y "{objdir}"Makefile.tem[12] - If {verify} == 1 - Echo Created Makefile in "`Directory`" - End If -Else If "`Exists "{srcdir}"mpw-make.in`" != "" - sed -e 's/^prefix = .*$/prefix = {mpw_prefix}/g' "{srcdir}"mpw-make.in >"{objdir}"Makefile.tem1 - sed -e "s/@DASH_C_FLAG@/{dash_c_flag}/" -e "s/@SEGMENT_FLAG(\([^)]*\))@/{segment_flag}}\1/" "{objdir}"Makefile.tem1 >"{objdir}"Makefile.tem2 - tr-7to8 "{objdir}"Makefile.tem2 >>"{objdir}"Makefile.tem - If "`Exists "{objdir}"mk.sed`" != "" - sed -f "{objdir}"mk.sed "{objdir}"Makefile.tem >"{objdir}"Makefile.tem2 - Rename -y "{objdir}"Makefile.tem2 "{objdir}"Makefile.tem - End If - MoveIfChange "{objdir}"Makefile.tem "{objdir}"Makefile - Delete -i -y "{objdir}"Makefile.tem[12] - If {verify} == 1 - Echo Created Makefile in "`Directory`" - End If -End If - -# Produce a build script if the source is defined. - -If "`Exists "{srcdir}"mpw-build.in`" != "" - Echo "Set srcroot " {srcroot} > "{objdir}"mpw-build.tem - Echo "Set srcdir " {srcdir} >> "{objdir}"mpw-build.tem - Echo "Set target_canonical " {target_canonical} >> "{objdir}"mpw-build.tem - Echo "Set prefix " {prefix} >> "{objdir}"mpw-build.tem - tr-7to8 "{srcdir}"mpw-build.in >>"{objdir}"mpw-build.tem - MoveIfChange "{objdir}"mpw-build.tem "{objdir}"mpw-build - If {verify} == 1 - Echo Created mpw-build in "`Directory`" - End If -End If - -# Apply ourselves recursively to the list of subdirectories to configure. - -If {recurse} == 1 - For subdir In {configdirs} - Set savedir "`Directory`" - If "`Exists "{srcdir}{subdir}:"`" == "" - If {verify} == 1 - Echo No "{srcdir}{subdir}:" found, skipping - End If - Continue - End If - If {verify} == 1 - Echo Configuring {subdir}... - End If - If "`Exists "{objdir}{subdir}:"`" == "" - NewFolder "{objdir}{subdir}" - End If - SetDirectory "{objdir}{subdir}:" - "{ThisScript}" --target "{target_canonical}" --srcdir "{srcdir}{subdir}:" --srcroot "{srcroot}" --prefix "{prefix}" --cc "{host_cc}" {verifystr} {enable_options} {disable_options} - SetDirectory "{savedir}" - End For -End If - -SetDirectory "{savedir}" diff --git a/gnu/usr.bin/binutils/mpw-install b/gnu/usr.bin/binutils/mpw-install deleted file mode 100644 index 04c5aac2a4f..00000000000 --- a/gnu/usr.bin/binutils/mpw-install +++ /dev/null @@ -1,122 +0,0 @@ -# GNU Install script for MPW. - -Set OldExit "{Exit}" -Set Exit 0 - -Set TempUserStartup "{TempFolder}"__temp__UserStartup - -Echo '# UserStartup generated by GNU Install script' > "{TempUserStartup}" -Echo '' >> "{TempUserStartup}" - -# (should) Check that disk space is sufficient for installation. - -# Assume that the install script is where everything else is. - -Set thisdir "`Directory`" - -# Copy the binaries to the desired place. - -Confirm -t "Copy the binaries to somewhere else?" -Set TmpStatus {Status} -If {TmpStatus} == 0 - Set bindest "`GetFileName -d -m "Where to install the binaries?"`" - If {Status} == 0 - If "`Exists "{thisdir}bin"`" != "" - For afile In "{thisdir}"bin:\Option-x - Duplicate -y "{afile}" "{bindest}" - End For - Else - Echo "bin directory not found, exiting" - Exit 1 - End If - Else - Echo "No destination supplied, exiting" - Exit 1 - End If -Else If {TmpStatus} == 4 - # Use the existing directory. - Set bindest "{thisdir}bin:" -Else - # Cancelled from confirmation, escape altogether. - Exit 1 -End If - -# Copy the libraries to the desired place. - -Confirm -t "Copy the libraries to somewhere else?" -Set TmpStatus {Status} -If {TmpStatus} == 0 - Set libdest "`GetFileName -d -m "Where to install the libraries?"`" - If {Status} == 0 - If "`Exists "{thisdir}lib:"`" != "" - For afile In "{thisdir}"lib:\Option-x - Duplicate -y "{afile}" "{libdest}" - End For - Else - Echo "lib directory not found, exiting" - Exit 1 - End If - Else - Echo "No destination supplied, exiting" - Exit 1 - End If -Else If {TmpStatus} == 4 - # Use the existing directory. - Set libdest "{thisdir}lib:" -Else - # Cancelled from confirmation, escape altogether. - Exit 1 -End If - - -# Add the location of the binaries to the command path. - -Echo -n 'Set Commands "' >> "{TempUserStartup}" -Echo -n "{bindest}" >> "{TempUserStartup}" -Echo ',{Commands}"' >> "{TempUserStartup}" -Echo '' >> "{TempUserStartup}" - -# Set up GCC exec prefix. - -Set gcclibdir "{libdest}"gcc-lib: - -Echo -n 'Set GCC_EXEC_PREFIX "' >> "{TempUserStartup}" -Echo -n "{gcclibdir}" >> "{TempUserStartup}" -Echo '"' >> "{TempUserStartup}" -Echo "Export GCC_EXEC_PREFIX" >> "{TempUserStartup}" -Echo '' >> "{TempUserStartup}" - -# Set up path to libgcc.xcoff etc. - -Echo -n 'Set GCCPPCLibraries "' >> "{TempUserStartup}" -Echo -n "{libdest}" >> "{TempUserStartup}" -Echo '"' >> "{TempUserStartup}" -Echo "Export GCCPPCLibraries" >> "{TempUserStartup}" -Echo '' >> "{TempUserStartup}" - -# Display contents of UserStartup, confirm installation. - -Set UserStartupName "UserStartup\Option-8GNU" - -Echo "Contents of" {UserStartupName} "will be:" -Catenate "{TempUserStartup}" - -Confirm "Install {UserStartupName} into the MPW folder {MPW} ?" -If {Status} == 0 - Duplicate "{TempUserStartup}" "{MPW}{UserStartupName}" - Delete -y "{TempUserStartup}" -Else - Echo "{UserStartupName} file not installed" -End If - -# (should) Check HEXA resource, warn if low. - -# (should) Check for spaces in pathnames, warn if found. - -Echo "Installation was successful." -Echo "" -Echo "Be sure to review the usage notes in 'Read Me for MPW' before proceeding!" - -# Restore previous settings. - -Set Exit "{OldExit}" |