diff options
| author | obrien <obrien@FreeBSD.org> | 2000-05-12 23:15:20 +0000 |
|---|---|---|
| committer | obrien <obrien@FreeBSD.org> | 2000-05-12 23:15:20 +0000 |
| commit | 2a9ea95d682586d2b0c31da28d82a73d786c7c0a (patch) | |
| tree | 9d4ce42d357c391a11d77254b770908c02ecf672 /contrib/binutils/etc | |
| parent | bffe850874e72664f78cf171ab1c4339b9b63cab (diff) | |
| download | FreeBSD-src-2a9ea95d682586d2b0c31da28d82a73d786c7c0a.zip FreeBSD-src-2a9ea95d682586d2b0c31da28d82a73d786c7c0a.tar.gz | |
Import of Binutils 2.10 snapshot.
Diffstat (limited to 'contrib/binutils/etc')
| -rw-r--r-- | contrib/binutils/etc/ChangeLog | 507 | ||||
| -rw-r--r-- | contrib/binutils/etc/Makefile.in | 88 | ||||
| -rw-r--r-- | contrib/binutils/etc/add-log.el | 573 | ||||
| -rw-r--r-- | contrib/binutils/etc/add-log.vi | 11 | ||||
| -rw-r--r-- | contrib/binutils/etc/configbuild.ein | 149 | ||||
| -rw-r--r-- | contrib/binutils/etc/configbuild.fig | 50 | ||||
| -rw-r--r-- | contrib/binutils/etc/configbuild.jin | bin | 0 -> 11123 bytes | |||
| -rw-r--r-- | contrib/binutils/etc/configbuild.tin | 9 | ||||
| -rw-r--r-- | contrib/binutils/etc/configdev.ein | 185 | ||||
| -rw-r--r-- | contrib/binutils/etc/configdev.fig | 80 | ||||
| -rw-r--r-- | contrib/binutils/etc/configdev.jin | bin | 0 -> 17967 bytes | |||
| -rw-r--r-- | contrib/binutils/etc/configdev.tin | 17 | ||||
| -rw-r--r-- | contrib/binutils/etc/configure.texi | 4066 |
13 files changed, 4099 insertions, 1636 deletions
diff --git a/contrib/binutils/etc/ChangeLog b/contrib/binutils/etc/ChangeLog new file mode 100644 index 0000000..0453a3e --- /dev/null +++ b/contrib/binutils/etc/ChangeLog @@ -0,0 +1,507 @@ +1999-04-01 Jim Blandy <jimb@zwingli.cygnus.com> + + * add-log.el, add-log.vi: New files. + +Wed Jan 20 01:33:50 1999 Angela Marie Thomas (angela@cygnus.com) + + * comp-tools-verify: Remove some checks that are no longer valid. + +1998-12-03 Nick Clifton <nickc@cygnus.com> + + * targetdoc/fr30.texi: New document. + +Thu Oct 1 21:15:59 1998 Angela Marie Thomas (angela@cygnus.com) + + * comp-tools-fix, cross-tools-fix: Replace /usr/include + with ${FIXINCDIR}. + +Tue Aug 11 19:22:11 1998 Doug Evans <devans@canuck.cygnus.com> + + * make-rel-sym-tree (version): Update calculation. + +Fri Jun 12 21:34:01 1998 Ian Lance Taylor <ian@cygnus.com> + + * configure.texi: Various additions. + * Makefile.in (TEXI2HTML, DVIPS): New variables. + (standards.ps): New target. + (configure.dvi): Copy .tin files in as well. + (configure.ps, configure.html): New targets. + (clean): Remove configdev.jpg and configbuild.jpg. + * configdev.fig: New file. + * configdev.ein: New file (EPS version of configdev.fig). + * configdev.jin: New file (JPEG version of configdev.fig). + * configbuild.fig: New file. + * configbuild.ein: New file (EPS version of configbuild.fig). + * configbuild.jin: New file (JPEG version of configbuild.fig). + +Wed Jun 10 14:41:25 1998 Ian Lance Taylor <ian@cygnus.com> + + * configure.texi: New file. + * configdev.tin: New file. + * configbuild.tin: New file. + * Makefile.in (MAKEINFO): Use makeinfo from texinfo directory if + it exists. + (TEXI2DVI): Likewise for texi2dvi. + (INFOFILES): Add configure.info. + (DVIFILES): Add configure.dvi. + (info): Only build info files if the source files exist. + (install-info): Only install info files if they exist. + (dvi): Only build DVI files if the sources files exist. + (configure.info): New target. + (configure.dvi): New target. + (clean): Remove configdev and configbuild derived files. + + Remove obsolete documentation. + * intro.texi: Remove. + * install.texi: Remove. + * config-names.texi: Remove. + * screen1.eps: Remove. + * screen1.obj: Remove. + * screen2.eps: Remove. + * screen2.obj: Remove. + * Makefile.in: Remove references to the above. + +Thu May 21 14:34:51 1998 Nick Clifton <nickc@cygnus.com> + + * targetdoc/arm-interwork.texi: Add note about ignoring linker + warning message when using --support-old-code. + +Mon May 18 14:27:37 1998 Angela Marie Thomas (angela@cygnus.com) + + * Install.in, comp-tools-fix, comp-tools-verify, cross-tools-fix: + Use $GCCvn rather than substitute everywhere. + +Thu May 14 14:43:10 1998 Nick Clifton <nickc@cygnus.com> + + * targetdoc/arm-interwork.texi: Document dlltool support of + interworking. + +Thu May 7 16:49:38 1998 Jason Molenda (crash@bugshack.cygnus.com) + + * Install.in: Remove references to TCL_LIBRARY, TK_LIBRARY, + and GDBTK_FILENAME. + +Wed Apr 1 17:11:44 1998 Nick Clifton <nickc@cygnus.com> + + * targetdoc/arm-interwork.texi: Document ARM/thumb interworking. + +Tue Mar 31 15:28:20 1998 Ian Lance Taylor <ian@cygnus.com> + + * standards.texi, make-stds.texi: Update to current FSF versions. + * Makefile.in (standards.info): Depend upon make-std.texi. + +Tue Mar 24 16:13:26 1998 Stu Grossman <grossman@bhuna.cygnus.co.uk> + + * configure: Regenerate with autoconf 2.12.1 to fix shell issues + for NT native builds. + +Mon Mar 9 16:41:04 1998 Doug Evans <devans@canuck.cygnus.com> + + * make-rel-sym-tree (binprogs): Add objcopy. + +Tue Feb 24 18:11:58 1998 Doug Evans <devans@canuck.cygnus.com> + + * make-rel-sym-tree: as.new -> as-new, ld.new -> ld-new + nm.new -> nm-new. Make symlinks to crt*.o. + +Fri Nov 21 12:54:58 1997 Manfred Hollstein <manfred@s-direktnet.de> + + * Makefile.in: Add --no-split argument to avoid creating files + with names longer than 14 characters. + +Thu Sep 25 13:13:11 1997 Jason Molenda (crash@pern.cygnus.com) + + * intro.texi: Add closing ifset. + +Mon Sep 1 10:31:32 1997 Angela Marie Thomas (angela@cygnus.com) + + * Install.in: Move setting HOST and TARGET to the beginning + of the file for editing convenience. + +Mon Sep 1 10:28:37 1997 Angela Marie Thomas (angela@cygnus.com) + + * Install.in.: More friendly options/messages when extracting + from a file instead of a tape device. + +Tue Jun 17 15:50:23 1997 Angela Marie Thomas (angela@cygnus.com) + + * Install.in: Add /usr/bsd to PATH for Irix (home of compress) + +Thu Jun 12 13:47:00 1997 Angela Marie Thomas (angela@cygnus.com) + + * Install.in (show_exec_prefix_msg): fix quoting + +Wed Jun 4 15:31:43 1997 Jason Molenda (crash@godzilla.cygnus.co.jp) + + * rebuilding.texi: Removed. + +Sat May 24 18:02:20 1997 Angela Marie Thomas (angela@cygnus.com) + + * cross-tools-fix: Remove host check since it doesn't matter + for this case. + * Install.in (guess_system): clean up more unused hosts. + * Install.in, cross-tools-fix, comp-tools-fix, comp-tools-verify: + Hack for host check to not warn the user for certain cases. + +Fri May 23 23:46:10 1997 Angela Marie Thomas (angela@cygnus.com) + + * subst-strings: Remove a lot of unused code + * Install.in: Remove reference to TAPEdflt, use variables instead of + string substitution when able. + +Fri Apr 11 17:25:52 1997 Ian Lance Taylor <ian@cygnus.com> + + * configure.in: Change file named in AC_INIT to Makefile.in. + * configure: Rebuild. + +Fri Apr 11 18:12:42 1997 Jason Molenda (crash@godzilla.cygnus.co.jp) + + * Install.in (guess_system): Back out change to INSTALLHOST to + call all IRIX systems "mips-sgi-irix4" + + * Makefile.in: Remove references to configure.texi and cfg-paper.texi. + +Thu Apr 10 23:26:45 1997 Jason Molenda (crash@godzilla.cygnus.co.jp) + + * srctree.texi, emacs-relnotes.texi, cfg-paper.texi: Remove. + * Install.in: Remove Ultrix-specific hacks. + Update Cygnus phone numbers. + (guess_system): Remove some old systems (Ultrix, OSF1 v1 & 2, + m68k-HPUX, m68k SunOS, etc.) + (show_gnu_root_msg): Remove. + Removed all the remove option code. + +Thu Apr 10 23:23:33 1997 Jason Molenda (crash@godzilla.cygnus.co.jp) + + * configure.man, configure.texi: Remote. + +Mon Apr 7 18:15:00 1997 Brendan Kehoe <brendan@cygnus.com> + + * Fix the version string for OSF1 4.0 to recognize either + V4.* or X4.* + +Mon Apr 7 15:34:47 1997 Ian Lance Taylor <ian@cygnus.com> + + * standards.texi, make-stds.texi: Update to current FSF versions. + +Tue Nov 19 15:36:14 1996 Doug Evans <dje@canuck.cygnus.com> + + * make-rel-sym-tree: New file. + +Wed Oct 23 00:34:07 1996 Angela Marie Thomas (angela@cygnus.com) + + * Lots of patches from progressive... + * Install.in: restore DDOPTS for AIX 4.x + * Install.in, subst-strings: add case for DG Aviion + * subst-strings: fix typo in INSTALLdir var setting + * comp-tools-verify: set SHLIB_PATH for shared libs + * Install.in, subst-strings: add case for solaris2.5 + * Install.in: fix regression for hppa1.1 check + * comp-tools-fix: set LD_LIBRARY_PATH + * comp-tools-fix: If fixincludes fixes /usr/include/limits.h, + install it as syslimits.h. + +Wed Oct 16 19:20:42 1996 Michael Meissner <meissner@tiktok.cygnus.com> + + * Install.in (guess_system): Treat powerpc-ibm-aix4.1 the same as + rs6000-ibm-aix4.1, since the compiler now uses common mode by + default. + +Wed Oct 2 15:39:07 1996 Jason Molenda (crash@godzilla.cygnus.co.jp) + + * configure.in (AC_PROG_INSTALL): Added. + * Makefile.in (distclean): Remove config.cache. + +Wed Oct 2 14:33:58 1996 Jason Molenda (crash@godzilla.cygnus.co.jp) + + * configure.in: Switch to autoconf configure.in. + * configure: New. + * Makefile.in: Use autoconf-substituted values. + +Tue Jun 25 18:56:08 1996 Jason Molenda (crash@godzilla.cygnus.co.jp) + + * Makefile.in (datadir): Changed to $(prefix)/share. + +Fri Mar 29 11:38:01 1996 J.T. Conklin (jtc@lisa.cygnus.com) + + * configure.man: Changed to be recognized by catman -w on Solaris. + +Wed Dec 6 15:40:28 1995 Doug Evans <dje@canuck.cygnus.com> + + * comp-tools-fix (fixincludes): Define FIXPROTO_DEFINES from + .../install-tools/fixproto-defines. + +Sun Nov 12 19:31:27 1995 Jason Molenda (crash@phydeaux.cygnus.com) + + * comp-tools-verify (verify_cxx_initializers): delete argv, + argc declarations, add -static to compile line. + (verify_cxx_hello_world): delete argv, argc declarations, add + -static to compile line. + +Wed Sep 20 13:21:52 1995 Ian Lance Taylor <ian@cygnus.com> + + * Makefile.in (maintainer-clean): New target, synonym for + realclean. + +Mon Aug 28 17:25:49 1995 Jason Molenda (crash@phydeaux.cygnus.com) + + * Install.in (PATH): add /usr/ucb to $PATH (for SunOS 4.1.x). + +Tue Aug 15 21:51:58 1995 Jason Molenda (crash@phydeaux.cygnus.com) + + * Install.in (guess_system): Match OSF/1 v3.x as the same as + v2.x--v2.x binaries are upward compatible. + +Tue Aug 15 21:46:54 1995 Jason Molenda (crash@phydeaux.cygnus.com) + + * Install.in (guess_system): recognize HP 9000/800 systems as the + same as HP 9000/700 systems. + +Tue Aug 8 13:11:56 1995 Brendan Kehoe <brendan@lisa.cygnus.com> + + * Install.in: For emacs, run show_emacs_alternate_msg and exit. + (show_emacs_alternate_msg): New message saying how emacs can't be + installed in an alternate prefix. + +Thu Jun 8 00:42:56 1995 Angela Marie Thomas <angela@cirdan.cygnus.com> + + * subst-strings: change du commands to $BINDIR/. & $SRCDIR/. just + in case they are symlinks. + +Tue Apr 18 14:23:10 1995 J.T. Conklin <jtc@rtl.cygnus.com> + + * cdk-fix: Extracted table of targets that don't need their + headers fixed from gcc's configure script. + + * cdk-fix, cdk-verify: Use ${HOST} instead of ||HOSTstr|| + + * cdk-fix, cdk-verify: New files, install script fragments used + for Cygnus Developer's Kit. + + * Install.in (do_mkdir): New function. + + * Install.in: Added support for --with and --without options. + Changed so that tape commands are not run when extracting + from a file. + (do_mt): Changed to take only one argument. + +Wed Mar 29 11:16:38 1995 Jason Molenda (crash@phydeaux.cygnus.com) + + * Install.in: catch UNAME==alpha-dec-osf2.x and correct entry for + alpha-dec-osf1.x + +Fri Jan 27 12:04:29 1995 J.T. Conklin <jtc@rtl.cygnus.com> + + * subst-strings (mips-sgi-irix5): New entry in table. + +Thu Jan 19 12:15:44 1995 J.T. Conklin <jtc@rtl.cygnus.com> + + * Install.in: Major rewrite, bundle dependent code (for example, + fixincludes for comp-tools) will be inserted into the Install + script when it is generated. + +Tue Jan 17 16:51:32 1995 Ian Lance Taylor <ian@sanguine.cygnus.com> + + * Makefile.in (Makefile): Rebuild using $(SHELL). + +Thu Nov 3 19:30:33 1994 Ken Raeburn <raeburn@cujo.cygnus.com> + + * Makefile.in (install-info): Depend on info. + +Fri Aug 19 16:16:38 1994 Jason Molenda (crash@phydeaux.cygnus.com) + + * Install.in: set $FIX_HEADER so fixproto can find fix-header. + +Fri May 6 16:18:58 1994 Jason Molenda (crash@sendai.cygnus.com) + + * Makefile.in (install-info): add a semicolon in the if statement. + +Fri Apr 29 16:56:07 1994 David J. Mackenzie (djm@rtl.cygnus.com) + + * cfg-paper.texi: Update some outdated information. + + * Makefile.in (install-info): Pass file, not directory, as last + arg to INSTALL_DATA. + (uninstall): New target. + +Thu Apr 28 14:42:22 1994 David J. Mackenzie (djm@rtl.cygnus.com) + + * configure.texi: Comment out @smallbook. + + * Makefile.in: Define TEXI2DVI and TEXIDIR, and use the latter. + Remove info files in realclean, not clean, per coding standards. + Remove TeX output in clean. + +Tue Apr 26 17:18:03 1994 Jason Molenda (crash@sendai.cygnus.com) + + * Install.in: fixincludes output is actually put in fixincludes.log, + but echo'ed messages claim it is fixinc.log. This is the same + messages as I logged in March 4 1994, but for some reason we found + the change hadn't been done. I'll have to dig through the logs + and find out what I really did do that day. :) + +Mon Apr 25 20:28:19 1994 Jason Molenda (crash@sendai.cygnus.com) + + * Install.in: use eval to call do_mt() for Ultrix brokenness. + +Mon Apr 25 20:00:00 1994 Jason Molenda (crash@sendai.cygnus.com) + + * Install.in(do_mt): exit with error status 1 if # of parameters + != 3. + +Mon Apr 25 19:42:36 1994 Jason Molenda (crash@sendai.cygnus.com) + + * Install.in: lose TAPE_FORWARD and TAPE_REWIND, add do_mt() + to do all tape movement operations. Currently untested. Addresses + PR # 4886 from bull. + + * Install.in: add 1994 to the copyright thing. + +Fri Apr 22 19:05:13 1994 David J. Mackenzie (djm@rtl.cygnus.com) + + * standards.texi: Update from FSF. + +Fri Apr 22 15:46:10 1994 Jason Molenda (crash@cygnus.com) + + * Install.in: Add $DDOPTS, has ``bs=124b'' for all systems except + AIX (some versions of AIX don't understand bs=124b. Silly OS). + +Mon Apr 4 22:55:05 1994 Jason Molenda (crash@sendai.cygnus.com) + + * Install.in: null out $TOOLS before adding stuff to it + non-destructively. + +Wed Mar 30 21:45:35 1994 David J. Mackenzie (djm@rtl.cygnus.com) + + * standards.texi: Fix typo. + + * configure.texi, configure.man: Document --disable-. + +Mon Mar 28 13:22:15 1994 David J. Mackenzie (djm@rtl.cygnus.com) + + * standards.texi: Update from FSF. + +Sat Mar 26 09:21:44 1994 David J. Mackenzie (djm@rtl.cygnus.com) + + * standards.texi, make-stds.texi: Update from FSF. + +Fri Mar 25 22:59:45 1994 David J. Mackenzie (djm@rtl.cygnus.com) + + * configure.texi, configure.man: Document --enable-* options. + +Wed Mar 23 23:38:24 1994 Jason Molenda (crash@sendai.cygnus.com) + + * Install.in: set CPP to be gcc -E for fixincludes. + +Wed Mar 23 13:42:48 1994 Jason Molenda (crash@sendai.cygnus.com) + + * Install.in: set PATH to $PATH:/bin:/usr/bin so we can pick + up native tools even if the user doesn't have them in his + path. + + * Install.in: ``hppa-1.1-hp-hpux'' -> ``hppa1.1-hp-hpux''. + +Tue Mar 15 22:09:20 1994 Jason Molenda (crash@sendai.cygnus.com) + + * Install.in: TAPE_REWIND and TAPE_FORWARD variables for Unixunaware, + added switch statement to detect if system is Unixunaware. + +Fri Mar 4 12:10:30 1994 Jason Molenda (crash@sendai.cygnus.com) + + * Install.in: fixincludes output is actually put in fixincludes.log, + but echo'ed messages claim it is fixinc.log. + +Wed Nov 3 02:58:02 1993 Jeffrey Osier (jeffrey@thepub.cygnus.com) + + * subst-strings: output TEXBUNDLE for more install notes matching + * install-texi.in: PRMS info now exists + +Tue Oct 26 16:57:12 1993 K. Richard Pixley (rich@sendai.cygnus.com) + + * subst-strings: match solaris*. Also, add default case to catch + and error out for unrecognized systems. + +Thu Aug 19 18:21:31 1993 david d `zoo' zuhn (zoo@rtl.cygnus.com) + + * Install.in: handle the new fixproto work + +Mon Jul 19 12:05:41 1993 david d `zoo' zuhn (zoo@cirdan.cygnus.com) + + * Install.in: remove "MT=tctl" for AIX (not needed, and barely + worked anyway) + +Mon Jun 14 19:09:22 1993 Jeffrey Osier (jeffrey@cygnus.com) + + * subst-strings: changed HOST to recognize Solaris for install notes + +Thu Jun 10 16:01:25 1993 Jeffrey Osier (jeffrey@cygnus.com) + + * dos-inst.texi: new file. + +Wed Jun 9 19:23:59 1993 Jeffrey Osier (jeffrey@rtl.cygnus.com) + + * install-texi.in: added conditionals (nearly complete) + cleaned up + added support for other releases (not done) + +Wed Jun 9 15:53:58 1993 Jim Kingdon (kingdon@cygnus.com) + + * Makefile.in (install-info): Use INSTALL_DATA. + ({dist,real}clean): Also delete Makefile and config.status. + +Fri Jun 4 17:09:56 1993 Jeffrey Osier (jeffrey@cygnus.com) + + * subst-strings: added data for OS_STRING + + * subst-strings: added support for OS_STRING + +Thu Jun 3 00:37:01 1993 david d `zoo' zuhn (zoo at cirdan.cygnus.com) + + * Install.in: pull COPYING and COPYING.LIB off of the tape + +Tue Jun 1 16:52:08 1993 david d `zoo' zuhn (zoo at cirdan.cygnus.com) + + * subst-strings: replace RELEASE_DIR too + +Mon Mar 22 23:55:27 1993 david d `zoo' zuhn (zoo at cirdan.cygnus.com) + + * Makefile.in: add installcheck target + +Wed Mar 17 02:21:15 1993 david d `zoo' zuhn (zoo at cirdan.cygnus.com) + + * Install.in: fix 'source only' extraction bug where it looked for + the src dir under H-<host>/src instead of src; also remove stray + reference to EMACSHIBIN + +Mon Mar 15 01:25:45 1993 david d `zoo' zuhn (zoo at cirdan.cygnus.com) + + * make-stds.texi: added 'installcheck' to the standard targets + +Tue Mar 9 19:48:28 1993 david d `zoo' zuhn (zoo at cirdan.cygnus.com) + + * standards.texi: added INFO-DIR-ENTRY, updated version from the FSF + +Tue Feb 9 12:40:23 1993 Ian Lance Taylor (ian@cygnus.com) + + * Makefile.in (standards.info): Added -I$(srcdir) to find + make-stds.texi. + +Mon Feb 1 16:32:56 1993 david d `zoo' zuhn (zoo at cirdan.cygnus.com) + + * standards.texi: updated to latest FSF version, which includes: + + * make-stds.texi: new file + +Mon Nov 30 01:31:40 1992 david d `zoo' zuhn (zoo at cirdan.cygnus.com) + + * install-texi.in, relnotes.texi, intro.texi: changed Cygnus phone + numbers from the old Palo Alto ones to the new Mtn. View numbers + +Mon Nov 16 16:50:43 1992 david d `zoo' zuhn (zoo at cirdan.cygnus.com) + + * Makefile.in: define $(RM) to "rm -f" + +Sun Oct 11 16:05:48 1992 david d `zoo' zuhn (zoo at cirdan.cygnus.com) + + * intro.texi: added INFO-DIR-ENTRY + diff --git a/contrib/binutils/etc/Makefile.in b/contrib/binutils/etc/Makefile.in index c490082..eedc8c9 100644 --- a/contrib/binutils/etc/Makefile.in +++ b/contrib/binutils/etc/Makefile.in @@ -31,8 +31,14 @@ INSTALL = @INSTALL@ INSTALL_PROGRAM = @INSTALL_PROGRAM@ INSTALL_DATA = @INSTALL_DATA@ -MAKEINFO = makeinfo -TEXI2DVI = texi2dvi +MAKEINFO = `if [ -f ../texinfo/makeinfo/makeinfo ]; \ + then echo ../texinfo/makeinfo/makeinfo; \ + else echo makeinfo; fi` +TEXI2DVI = `if [ -f ../texinfo/util/texi2dvi ]; \ + then echo ../texinfo/util/texi2dvi; \ + else echo texi2dvi; fi` +TEXI2HTML = texi2html +DVIPS = dvips # Where to find texinfo.tex to format documentation with TeX. TEXIDIR = $(srcdir)/../texinfo @@ -40,8 +46,8 @@ TEXIDIR = $(srcdir)/../texinfo #### Host, target, and site specific Makefile fragments come in here. ### -INFOFILES = standards.info -DVIFILES = standards.dvi +INFOFILES = standards.info configure.info +DVIFILES = standards.dvi configure.dvi all: @@ -49,26 +55,88 @@ install: uninstall: -info: $(INFOFILES) +info: + for f in $(INFOFILES); do \ + if test -f $(srcdir)/`echo $$f | sed -e 's/.info$$/.texi/'`; then \ + if $(MAKE) "MAKEINFO=$(MAKEINFO)" $$f; then \ + true; \ + else \ + exit 1; \ + fi; \ + fi; \ + done install-info: info - if test ! -f standards.info ; then cd $(srcdir); fi; \ - for i in standards.info*; do \ - $(INSTALL_DATA) $$i $(infodir)/$$i; \ + $(SHELL) $(srcdir)/../mkinstalldirs $(infodir) + if test ! -f standards.info; then cd $(srcdir); fi; \ + if test -f standards.info; then \ + for i in standards.info*; do \ + $(INSTALL_DATA) $$i $(infodir)/$$i; \ + done; \ + fi + if test ! -f configure.info; then cd $(srcdir); fi; \ + if test -f configure.info; then \ + for i in configure.info*; do \ + $(INSTALL_DATA) $$i $(infodir)/$$i; \ + done; \ + fi + +dvi: + for f in $(DVIFILES); do \ + if test -f $(srcdir)/`echo $$f | sed -e 's/.dvi$$/.texi/'`; then \ + if $(MAKE) "TEXI2DVI=$(TEXI2DVI)" $$f; then \ + true; \ + else \ + exit 1; \ + fi; \ + fi; \ done -dvi: $(DVIFILES) - standards.info: $(srcdir)/standards.texi $(srcdir)/make-stds.texi $(MAKEINFO) --no-split -I$(srcdir) -o standards.info $(srcdir)/standards.texi standards.dvi: $(srcdir)/standards.texi TEXINPUTS=$(TEXIDIR):$$TEXINPUTS $(TEXI2DVI) $(srcdir)/standards.texi +standards.ps: standards.dvi + $(DVIPS) standards.dvi -o standards.ps + +# makeinfo requires images to be in the current directory. +configure.info: $(srcdir)/configure.texi $(srcdir)/configdev.tin $(srcdir)/configbuild.tin + rm -f configdev.txt configbuild.txt + cp $(srcdir)/configdev.tin configdev.txt + cp $(srcdir)/configbuild.tin configbuild.txt + $(MAKEINFO) -I$(srcdir) -o configure.info $(srcdir)/configure.texi + rm -f configdev.txt configbuild.txt + +# texi2dvi wants both the .txt and the .eps files. +configure.dvi: $(srcdir)/configure.texi $(srcdir)/configdev.tin $(srcdir)/configbuild.tin $(srcdir)/configdev.ein $(srcdir)/configbuild.ein + rm -f configdev.txt configbuild.txt + cp $(srcdir)/configdev.tin configdev.txt + cp $(srcdir)/configbuild.tin configbuild.txt + rm -f configdev.eps configbuild.eps + cp $(srcdir)/configdev.ein configdev.eps + cp $(srcdir)/configbuild.ein configbuild.eps + TEXINPUTS=$(TEXIDIR):$$TEXINPUTS $(TEXI2DVI) $(srcdir)/configure.texi + rm -f configdev.txt configbuild.txt + rm -f configdev.eps configbuild.eps + +# dvips requires images to be in the current directory +configure.ps: configure.dvi $(srcdir)/configdev.ein $(srcdir)/configbuild.ein + rm -f configdev.eps configbuild.eps + cp $(srcdir)/configdev.ein configdev.eps + cp $(srcdir)/configbuild.ein configbuild.eps + $(DVIPS) configure.dvi -o configure.ps + rm -f configdev.eps configbuild.eps + +configure.html: $(srcdir)/configure.texi + $(TEXI2HTML) -split_chapter $(srcdir)/configure.texi clean: rm -f *.aux *.cp *.cps *.dvi *.fn *.fns *.ky *.kys *.log rm -f *.pg *.pgs *.toc *.tp *.tps *.vr *.vrs + rm -f configdev.txt configbuild.txt configdev.eps configbuild.eps + rm -f configdev.jpg configbuild.jpg mostlyclean: clean diff --git a/contrib/binutils/etc/add-log.el b/contrib/binutils/etc/add-log.el new file mode 100644 index 0000000..60c88e8 --- /dev/null +++ b/contrib/binutils/etc/add-log.el @@ -0,0 +1,573 @@ +;;; ============ NOTE WELL! ============= +;;; +;;; You only need to use this file if you're using a version of Emacs +;;; prior to 20.1 to work on GDB. The only difference between this +;;; and the standard add-log.el provided with 19.34 is that it +;;; generates dates using the terser format used by Emacs 20. This is +;;; the format recommended for use in GDB ChangeLogs. +;;; +;;; To use this code, you should create a directory `~/elisp', save the code +;;; below in `~/elisp/add-log.el', and then put something like this in +;;; your `~/.emacs' file, to tell Emacs where to find it: +;;; +;;; (setq load-path +;;; (cons (expand-file-name "~/elisp") +;;; load-path)) +;;; +;;; If you want, you can also byte-compile it --- it'll run a little +;;; faster, and use a little less memory. (Not that those matter much for +;;; this file.) To do that, after you've saved the text as +;;; ~/elisp/add-log.el, bring it up in Emacs, and type +;;; +;;; C-u M-x byte-compile-file +;;; +;;; --- Jim Blandy + +;;; add-log.el --- change log maintenance commands for Emacs + +;; Copyright (C) 1985, 1986, 1988, 1993, 1994 Free Software Foundation, Inc. + +;; Keywords: maint + +;; This file is part of GNU Emacs. + +;; GNU Emacs 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. + +;; GNU Emacs 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 GNU Emacs; see the file COPYING. If not, write to the +;; Free Software Foundation, Inc., 59 Temple Place - Suite 330, +;; Boston, MA 02111-1307, USA. + +;;; Commentary: + +;; This facility is documented in the Emacs Manual. + +;;; Code: + +(defvar change-log-default-name nil + "*Name of a change log file for \\[add-change-log-entry].") + +(defvar add-log-current-defun-function nil + "\ +*If non-nil, function to guess name of current function from surrounding text. +\\[add-change-log-entry] calls this function (if nil, `add-log-current-defun' +instead) with no arguments. It returns a string or nil if it cannot guess.") + +;;;###autoload +(defvar add-log-full-name nil + "*Full name of user, for inclusion in ChangeLog daily headers. +This defaults to the value returned by the `user-full-name' function.") + +;;;###autoload +(defvar add-log-mailing-address nil + "*Electronic mail address of user, for inclusion in ChangeLog daily headers. +This defaults to the value of `user-mail-address'.") + +(defvar change-log-font-lock-keywords + '(("^[SMTWF].+" . font-lock-function-name-face) ; Date line. + ("^\t\\* \\([^ :\n]+\\)" 1 font-lock-comment-face) ; File name. + ("(\\([^)\n]+\\)):" 1 font-lock-keyword-face)) ; Function name. + "Additional expressions to highlight in Change Log mode.") + +(defvar change-log-mode-map nil + "Keymap for Change Log major mode.") +(if change-log-mode-map + nil + (setq change-log-mode-map (make-sparse-keymap)) + (define-key change-log-mode-map "\M-q" 'change-log-fill-paragraph)) + +(defun change-log-name () + (or change-log-default-name + (if (eq system-type 'vax-vms) + "$CHANGE_LOG$.TXT" + (if (or (eq system-type 'ms-dos) (eq system-type 'windows-nt)) + "changelo" + "ChangeLog")))) + +;;;###autoload +(defun prompt-for-change-log-name () + "Prompt for a change log name." + (let* ((default (change-log-name)) + (name (expand-file-name + (read-file-name (format "Log file (default %s): " default) + nil default)))) + ;; Handle something that is syntactically a directory name. + ;; Look for ChangeLog or whatever in that directory. + (if (string= (file-name-nondirectory name) "") + (expand-file-name (file-name-nondirectory default) + name) + ;; Handle specifying a file that is a directory. + (if (file-directory-p name) + (expand-file-name (file-name-nondirectory default) + (file-name-as-directory name)) + name)))) + +;;;###autoload +(defun find-change-log (&optional file-name) + "Find a change log file for \\[add-change-log-entry] and return the name. + +Optional arg FILE-NAME specifies the file to use. +If FILE-NAME is nil, use the value of `change-log-default-name'. +If 'change-log-default-name' is nil, behave as though it were 'ChangeLog' +\(or whatever we use on this operating system). + +If 'change-log-default-name' contains a leading directory component, then +simply find it in the current directory. Otherwise, search in the current +directory and its successive parents for a file so named. + +Once a file is found, `change-log-default-name' is set locally in the +current buffer to the complete file name." + ;; If user specified a file name or if this buffer knows which one to use, + ;; just use that. + (or file-name + (setq file-name (and change-log-default-name + (file-name-directory change-log-default-name) + change-log-default-name)) + (progn + ;; Chase links in the source file + ;; and use the change log in the dir where it points. + (setq file-name (or (and buffer-file-name + (file-name-directory + (file-chase-links buffer-file-name))) + default-directory)) + (if (file-directory-p file-name) + (setq file-name (expand-file-name (change-log-name) file-name))) + ;; Chase links before visiting the file. + ;; This makes it easier to use a single change log file + ;; for several related directories. + (setq file-name (file-chase-links file-name)) + (setq file-name (expand-file-name file-name)) + ;; Move up in the dir hierarchy till we find a change log file. + (let ((file1 file-name) + parent-dir) + (while (and (not (or (get-file-buffer file1) (file-exists-p file1))) + (progn (setq parent-dir + (file-name-directory + (directory-file-name + (file-name-directory file1)))) + ;; Give up if we are already at the root dir. + (not (string= (file-name-directory file1) + parent-dir)))) + ;; Move up to the parent dir and try again. + (setq file1 (expand-file-name + (file-name-nondirectory (change-log-name)) + parent-dir))) + ;; If we found a change log in a parent, use that. + (if (or (get-file-buffer file1) (file-exists-p file1)) + (setq file-name file1))))) + ;; Make a local variable in this buffer so we needn't search again. + (set (make-local-variable 'change-log-default-name) file-name) + file-name) + +;;;###autoload +(defun add-change-log-entry (&optional whoami file-name other-window new-entry) + "Find change log file and add an entry for today. +Optional arg (interactive prefix) non-nil means prompt for user name and site. +Second arg is file name of change log. If nil, uses `change-log-default-name'. +Third arg OTHER-WINDOW non-nil means visit in other window. +Fourth arg NEW-ENTRY non-nil means always create a new entry at the front; +never append to an existing entry." + (interactive (list current-prefix-arg + (prompt-for-change-log-name))) + (or add-log-full-name + (setq add-log-full-name (user-full-name))) + (or add-log-mailing-address + (setq add-log-mailing-address user-mail-address)) + (if whoami + (progn + (setq add-log-full-name (read-input "Full name: " add-log-full-name)) + ;; Note that some sites have room and phone number fields in + ;; full name which look silly when inserted. Rather than do + ;; anything about that here, let user give prefix argument so that + ;; s/he can edit the full name field in prompter if s/he wants. + (setq add-log-mailing-address + (read-input "Mailing address: " add-log-mailing-address)))) + (let ((defun (funcall (or add-log-current-defun-function + 'add-log-current-defun))) + paragraph-end entry) + + (setq file-name (expand-file-name (find-change-log file-name))) + + ;; Set ENTRY to the file name to use in the new entry. + (and buffer-file-name + ;; Never want to add a change log entry for the ChangeLog file itself. + (not (string= buffer-file-name file-name)) + (setq entry (if (string-match + (concat "^" (regexp-quote (file-name-directory + file-name))) + buffer-file-name) + (substring buffer-file-name (match-end 0)) + (file-name-nondirectory buffer-file-name)))) + + (if (and other-window (not (equal file-name buffer-file-name))) + (find-file-other-window file-name) + (find-file file-name)) + (or (eq major-mode 'change-log-mode) + (change-log-mode)) + (undo-boundary) + (goto-char (point-min)) + (let ((heading (format "%s %s <%s>" + (format-time-string "%Y-%m-%d") + add-log-full-name + add-log-mailing-address))) + (if (looking-at (regexp-quote heading)) + (forward-line 1) + (insert heading "\n\n"))) + + ;; Search only within the first paragraph. + (if (looking-at "\n*[^\n* \t]") + (skip-chars-forward "\n") + (forward-paragraph 1)) + (setq paragraph-end (point)) + (goto-char (point-min)) + + ;; Now insert the new line for this entry. + (cond ((re-search-forward "^\\s *\\*\\s *$" paragraph-end t) + ;; Put this file name into the existing empty entry. + (if entry + (insert entry))) + ((and (not new-entry) + (let (case-fold-search) + (re-search-forward + (concat (regexp-quote (concat "* " entry)) + ;; Don't accept `foo.bar' when + ;; looking for `foo': + "\\(\\s \\|[(),:]\\)") + paragraph-end t))) + ;; Add to the existing entry for the same file. + (re-search-forward "^\\s *$\\|^\\s \\*") + (goto-char (match-beginning 0)) + ;; Delete excess empty lines; make just 2. + (while (and (not (eobp)) (looking-at "^\\s *$")) + (delete-region (point) (save-excursion (forward-line 1) (point)))) + (insert "\n\n") + (forward-line -2) + (indent-relative-maybe)) + (t + ;; Make a new entry. + (forward-line 1) + (while (looking-at "\\sW") + (forward-line 1)) + (while (and (not (eobp)) (looking-at "^\\s *$")) + (delete-region (point) (save-excursion (forward-line 1) (point)))) + (insert "\n\n\n") + (forward-line -2) + (indent-to left-margin) + (insert "* " (or entry "")))) + ;; Now insert the function name, if we have one. + ;; Point is at the entry for this file, + ;; either at the end of the line or at the first blank line. + (if defun + (progn + ;; Make it easy to get rid of the function name. + (undo-boundary) + (insert (if (save-excursion + (beginning-of-line 1) + (looking-at "\\s *$")) + "" + " ") + "(" defun "): ")) + ;; No function name, so put in a colon unless we have just a star. + (if (not (save-excursion + (beginning-of-line 1) + (looking-at "\\s *\\(\\*\\s *\\)?$"))) + (insert ": "))))) + +;;;###autoload +(defun add-change-log-entry-other-window (&optional whoami file-name) + "Find change log file in other window and add an entry for today. +Optional arg (interactive prefix) non-nil means prompt for user name and site. +Second arg is file name of change log. \ +If nil, uses `change-log-default-name'." + (interactive (if current-prefix-arg + (list current-prefix-arg + (prompt-for-change-log-name)))) + (add-change-log-entry whoami file-name t)) +;;;###autoload (define-key ctl-x-4-map "a" 'add-change-log-entry-other-window) + +;;;###autoload +(defun change-log-mode () + "Major mode for editing change logs; like Indented Text Mode. +Prevents numeric backups and sets `left-margin' to 8 and `fill-column' to 74. +New log entries are usually made with \\[add-change-log-entry] or \\[add-change-log-entry-other-window]. +Each entry behaves as a paragraph, and the entries for one day as a page. +Runs `change-log-mode-hook'." + (interactive) + (kill-all-local-variables) + (indented-text-mode) + (setq major-mode 'change-log-mode + mode-name "Change Log" + left-margin 8 + fill-column 74 + indent-tabs-mode t + tab-width 8) + (use-local-map change-log-mode-map) + ;; Let each entry behave as one paragraph: + ;; We really do want "^" in paragraph-start below: it is only the lines that + ;; begin at column 0 (despite the left-margin of 8) that we are looking for. + (set (make-local-variable 'paragraph-start) "\\s *$\\|\f\\|^\\sw") + (set (make-local-variable 'paragraph-separate) "\\s *$\\|\f\\|^\\sw") + ;; Let all entries for one day behave as one page. + ;; Match null string on the date-line so that the date-line + ;; is grouped with what follows. + (set (make-local-variable 'page-delimiter) "^\\<\\|^\f") + (set (make-local-variable 'version-control) 'never) + (set (make-local-variable 'adaptive-fill-regexp) "\\s *") + (set (make-local-variable 'font-lock-defaults) + '(change-log-font-lock-keywords t)) + (run-hooks 'change-log-mode-hook)) + +;; It might be nice to have a general feature to replace this. The idea I +;; have is a variable giving a regexp matching text which should not be +;; moved from bol by filling. change-log-mode would set this to "^\\s *\\s(". +;; But I don't feel up to implementing that today. +(defun change-log-fill-paragraph (&optional justify) + "Fill the paragraph, but preserve open parentheses at beginning of lines. +Prefix arg means justify as well." + (interactive "P") + (let ((end (save-excursion (forward-paragraph) (point))) + (beg (save-excursion (backward-paragraph)(point))) + (paragraph-start (concat paragraph-start "\\|\\s *\\s("))) + (fill-region beg end justify))) + +(defvar add-log-current-defun-header-regexp + "^\\([A-Z][A-Z_ ]*[A-Z_]\\|[-_a-zA-Z]+\\)[ \t]*[:=]" + "*Heuristic regexp used by `add-log-current-defun' for unknown major modes.") + +;;;###autoload +(defun add-log-current-defun () + "Return name of function definition point is in, or nil. + +Understands C, Lisp, LaTeX (\"functions\" are chapters, sections, ...), +Texinfo (@node titles), Perl, and Fortran. + +Other modes are handled by a heuristic that looks in the 10K before +point for uppercase headings starting in the first column or +identifiers followed by `:' or `=', see variable +`add-log-current-defun-header-regexp'. + +Has a preference of looking backwards." + (condition-case nil + (save-excursion + (let ((location (point))) + (cond ((memq major-mode '(emacs-lisp-mode lisp-mode scheme-mode + lisp-interaction-mode)) + ;; If we are now precisely at the beginning of a defun, + ;; make sure beginning-of-defun finds that one + ;; rather than the previous one. + (or (eobp) (forward-char 1)) + (beginning-of-defun) + ;; Make sure we are really inside the defun found, not after it. + (if (and (looking-at "\\s(") + (progn (end-of-defun) + (< location (point))) + (progn (forward-sexp -1) + (>= location (point)))) + (progn + (if (looking-at "\\s(") + (forward-char 1)) + (forward-sexp 1) + (skip-chars-forward " '") + (buffer-substring (point) + (progn (forward-sexp 1) (point)))))) + ((and (memq major-mode '(c-mode c++-mode c++-c-mode objc-mode)) + (save-excursion (beginning-of-line) + ;; Use eq instead of = here to avoid + ;; error when at bob and char-after + ;; returns nil. + (while (eq (char-after (- (point) 2)) ?\\) + (forward-line -1)) + (looking-at "[ \t]*#[ \t]*define[ \t]"))) + ;; Handle a C macro definition. + (beginning-of-line) + (while (eq (char-after (- (point) 2)) ?\\) ;not =; note above + (forward-line -1)) + (search-forward "define") + (skip-chars-forward " \t") + (buffer-substring (point) + (progn (forward-sexp 1) (point)))) + ((memq major-mode '(c-mode c++-mode c++-c-mode objc-mode)) + (beginning-of-line) + ;; See if we are in the beginning part of a function, + ;; before the open brace. If so, advance forward. + (while (not (looking-at "{\\|\\(\\s *$\\)")) + (forward-line 1)) + (or (eobp) + (forward-char 1)) + (beginning-of-defun) + (if (progn (end-of-defun) + (< location (point))) + (progn + (backward-sexp 1) + (let (beg tem) + + (forward-line -1) + ;; Skip back over typedefs of arglist. + (while (and (not (bobp)) + (looking-at "[ \t\n]")) + (forward-line -1)) + ;; See if this is using the DEFUN macro used in Emacs, + ;; or the DEFUN macro used by the C library. + (if (condition-case nil + (and (save-excursion + (end-of-line) + (while (= (preceding-char) ?\\) + (end-of-line 2)) + (backward-sexp 1) + (beginning-of-line) + (setq tem (point)) + (looking-at "DEFUN\\b")) + (>= location tem)) + (error nil)) + (progn + (goto-char tem) + (down-list 1) + (if (= (char-after (point)) ?\") + (progn + (forward-sexp 1) + (skip-chars-forward " ,"))) + (buffer-substring (point) + (progn (forward-sexp 1) (point)))) + (if (looking-at "^[+-]") + (get-method-definition) + ;; Ordinary C function syntax. + (setq beg (point)) + (if (and (condition-case nil + ;; Protect against "Unbalanced parens" error. + (progn + (down-list 1) ; into arglist + (backward-up-list 1) + (skip-chars-backward " \t") + t) + (error nil)) + ;; Verify initial pos was after + ;; real start of function. + (save-excursion + (goto-char beg) + ;; For this purpose, include the line + ;; that has the decl keywords. This + ;; may also include some of the + ;; comments before the function. + (while (and (not (bobp)) + (save-excursion + (forward-line -1) + (looking-at "[^\n\f]"))) + (forward-line -1)) + (>= location (point))) + ;; Consistency check: going down and up + ;; shouldn't take us back before BEG. + (> (point) beg)) + (let (end middle) + ;; Don't include any final newline + ;; in the name we use. + (if (= (preceding-char) ?\n) + (forward-char -1)) + (setq end (point)) + (backward-sexp 1) + ;; Now find the right beginning of the name. + ;; Include certain keywords if they + ;; precede the name. + (setq middle (point)) + (forward-word -1) + ;; Ignore these subparts of a class decl + ;; and move back to the class name itself. + (while (looking-at "public \\|private ") + (skip-chars-backward " \t:") + (setq end (point)) + (backward-sexp 1) + (setq middle (point)) + (forward-word -1)) + (and (bolp) + (looking-at "struct \\|union \\|class ") + (setq middle (point))) + (buffer-substring middle end))))))))) + ((memq major-mode + '(TeX-mode plain-TeX-mode LaTeX-mode;; tex-mode.el + plain-tex-mode latex-mode;; cmutex.el + )) + (if (re-search-backward + "\\\\\\(sub\\)*\\(section\\|paragraph\\|chapter\\)" nil t) + (progn + (goto-char (match-beginning 0)) + (buffer-substring (1+ (point));; without initial backslash + (progn + (end-of-line) + (point)))))) + ((eq major-mode 'texinfo-mode) + (if (re-search-backward "^@node[ \t]+\\([^,\n]+\\)" nil t) + (buffer-substring (match-beginning 1) + (match-end 1)))) + ((eq major-mode 'perl-mode) + (if (re-search-backward "^sub[ \t]+\\([^ \t\n]+\\)" nil t) + (buffer-substring (match-beginning 1) + (match-end 1)))) + ((eq major-mode 'fortran-mode) + ;; must be inside function body for this to work + (beginning-of-fortran-subprogram) + (let ((case-fold-search t)) ; case-insensitive + ;; search for fortran subprogram start + (if (re-search-forward + "^[ \t]*\\(program\\|subroutine\\|function\ +\\|[ \ta-z0-9*]*[ \t]+function\\)" + nil t) + (progn + ;; move to EOL or before first left paren + (if (re-search-forward "[(\n]" nil t) + (progn (forward-char -1) + (skip-chars-backward " \t")) + (end-of-line)) + ;; Use the name preceding that. + (buffer-substring (point) + (progn (forward-sexp -1) + (point))))))) + (t + ;; If all else fails, try heuristics + (let (case-fold-search) + (end-of-line) + (if (re-search-backward add-log-current-defun-header-regexp + (- (point) 10000) + t) + (buffer-substring (match-beginning 1) + (match-end 1)))))))) + (error nil))) + +(defvar get-method-definition-md) + +;; Subroutine used within get-method-definition. +;; Add the last match in the buffer to the end of `md', +;; followed by the string END; move to the end of that match. +(defun get-method-definition-1 (end) + (setq get-method-definition-md + (concat get-method-definition-md + (buffer-substring (match-beginning 1) (match-end 1)) + end)) + (goto-char (match-end 0))) + +;; For objective C, return the method name if we are in a method. +(defun get-method-definition () + (let ((get-method-definition-md "[")) + (save-excursion + (if (re-search-backward "^@implementation\\s-*\\([A-Za-z_]*\\)" nil t) + (get-method-definition-1 " "))) + (save-excursion + (cond + ((re-search-forward "^\\([-+]\\)[ \t\n\f\r]*\\(([^)]*)\\)?\\s-*" nil t) + (get-method-definition-1 "") + (while (not (looking-at "[{;]")) + (looking-at + "\\([A-Za-z_]*:?\\)\\s-*\\(([^)]*)\\)?[A-Za-z_]*[ \t\n\f\r]*") + (get-method-definition-1 "")) + (concat get-method-definition-md "]")))))) + + +(provide 'add-log) + +;;; add-log.el ends here diff --git a/contrib/binutils/etc/add-log.vi b/contrib/binutils/etc/add-log.vi new file mode 100644 index 0000000..efb8c77 --- /dev/null +++ b/contrib/binutils/etc/add-log.vi @@ -0,0 +1,11 @@ +Here is a vi macro to create entries in the recommended format for +GDB's ChangeLogs. + +map 1GO:r !date '+\%Y-\%m-\%d'2GA Jason Molenda (:r !whoamikJxA@:r !hostnameA)kJxkddjO
*
k$ + +It contains control and escape sequences, so don't just cut and paste it. +You'll need to change the "Jason Molenda" bit, of course. :-) Put this +in your $HOME/.exrc and when you type control-X in move-around-mode, +you'll have a changelog template inserted. + +--- Jason Molenda diff --git a/contrib/binutils/etc/configbuild.ein b/contrib/binutils/etc/configbuild.ein new file mode 100644 index 0000000..7a0e214 --- /dev/null +++ b/contrib/binutils/etc/configbuild.ein @@ -0,0 +1,149 @@ +%!PS-Adobe-2.0 EPSF-2.0 +%%Title: configbuild.fig +%%Creator: fig2dev Version 3.1 Patchlevel 1 +%%CreationDate: Fri Jun 12 20:13:16 1998 +%%For: ian@tito.cygnus.com (Ian Lance Taylor) +%%Orientation: Portrait +%%BoundingBox: 0 0 322 173 +%%Pages: 0 +%%BeginSetup +%%IncludeFeature: *PageSize Letter +%%EndSetup +%%EndComments +/$F2psDict 200 dict def +$F2psDict begin +$F2psDict /mtrx matrix put +/col-1 {} def +/col0 {0.000 0.000 0.000 srgb} bind def +/col1 {0.000 0.000 1.000 srgb} bind def +/col2 {0.000 1.000 0.000 srgb} bind def +/col3 {0.000 1.000 1.000 srgb} bind def +/col4 {1.000 0.000 0.000 srgb} bind def +/col5 {1.000 0.000 1.000 srgb} bind def +/col6 {1.000 1.000 0.000 srgb} bind def +/col7 {1.000 1.000 1.000 srgb} bind def +/col8 {0.000 0.000 0.560 srgb} bind def +/col9 {0.000 0.000 0.690 srgb} bind def +/col10 {0.000 0.000 0.820 srgb} bind def +/col11 {0.530 0.810 1.000 srgb} bind def +/col12 {0.000 0.560 0.000 srgb} bind def +/col13 {0.000 0.690 0.000 srgb} bind def +/col14 {0.000 0.820 0.000 srgb} bind def +/col15 {0.000 0.560 0.560 srgb} bind def +/col16 {0.000 0.690 0.690 srgb} bind def +/col17 {0.000 0.820 0.820 srgb} bind def +/col18 {0.560 0.000 0.000 srgb} bind def +/col19 {0.690 0.000 0.000 srgb} bind def +/col20 {0.820 0.000 0.000 srgb} bind def +/col21 {0.560 0.000 0.560 srgb} bind def +/col22 {0.690 0.000 0.690 srgb} bind def +/col23 {0.820 0.000 0.820 srgb} bind def +/col24 {0.500 0.190 0.000 srgb} bind def +/col25 {0.630 0.250 0.000 srgb} bind def +/col26 {0.750 0.380 0.000 srgb} bind def +/col27 {1.000 0.500 0.500 srgb} bind def +/col28 {1.000 0.630 0.630 srgb} bind def +/col29 {1.000 0.750 0.750 srgb} bind def +/col30 {1.000 0.880 0.880 srgb} bind def +/col31 {1.000 0.840 0.000 srgb} bind def + +end +save +-62.0 226.0 translate +1 -1 scale + +/clp {closepath} bind def +/ef {eofill} bind def +/gr {grestore} bind def +/gs {gsave} bind def +/l {lineto} bind def +/m {moveto} bind def +/n {newpath} bind def +/s {stroke} bind def +/slc {setlinecap} bind def +/slj {setlinejoin} bind def +/slw {setlinewidth} bind def +/srgb {setrgbcolor} bind def +/rot {rotate} bind def +/sc {scale} bind def +/tr {translate} bind def +/tnt {dup dup currentrgbcolor + 4 -2 roll dup 1 exch sub 3 -1 roll mul add + 4 -2 roll dup 1 exch sub 3 -1 roll mul add + 4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb} + bind def +/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul + 4 -2 roll mul srgb} bind def +/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def +/$F2psEnd {$F2psEnteredState restore end} def +%%EndProlog + +$F2psBegin +10 setmiterlimit + 0.06000 0.06000 sc +7.500 slw +% Polyline +n 1050 900 m 2100 900 l 2100 1425 l 1050 1425 l clp gs col-1 s gr +% Polyline +n 1500 1425 m 1500 2100 l gs col-1 s gr +n 1530.00 1980.00 m 1500.00 2100.00 l 1470.00 1980.00 l 1500.50 1980.50 l 1530.00 1980.00 l clp gs 0.00 setgray ef gr gs col-1 s gr +% Polyline +n 1500 2625 m 1500 3300 l gs col-1 s gr +n 1530.00 3180.00 m 1500.00 3300.00 l 1470.00 3180.00 l 1500.50 3180.50 l 1530.00 3180.00 l clp gs 0.00 setgray ef gr gs col-1 s gr +% Polyline +n 2925 900 m 3825 900 l 3825 1425 l 2925 1425 l clp gs col-1 s gr +% Polyline +n 1155 2100 m 1050 2100 1050 2520 105 arcto 4 {pop} repeat 1050 2625 2220 2625 105 arcto 4 {pop} repeat 2325 2625 2325 2205 105 arcto 4 {pop} repeat 2325 2100 1155 2100 105 arcto 4 {pop} repeat clp gs col-1 s gr +% Polyline +n 2850 2100 m 4125 2100 l 4125 2625 l 2850 2625 l clp gs col-1 s gr +% Polyline +n 3375 1425 m 3375 2100 l gs col-1 s gr +n 3405.00 1980.00 m 3375.00 2100.00 l 3345.00 1980.00 l 3375.50 1980.50 l 3405.00 1980.00 l clp gs 0.00 setgray ef gr gs col-1 s gr +% Polyline +n 5100 900 m 6300 900 l 6300 1350 l 5100 1350 l clp gs col-1 s gr +% Polyline +n 5625 1350 m 5625 2100 l gs col-1 s gr +n 5655.00 1980.00 m 5625.00 2100.00 l 5595.00 1980.00 l 5625.50 1980.50 l 5655.00 1980.00 l clp gs 0.00 setgray ef gr gs col-1 s gr +% Polyline +n 5205 2100 m 5100 2100 5100 2520 105 arcto 4 {pop} repeat 5100 2625 6270 2625 105 arcto 4 {pop} repeat 6375 2625 6375 2205 105 arcto 4 {pop} repeat 6375 2100 5205 2100 105 arcto 4 {pop} repeat clp gs col-1 s gr +% Polyline +n 5625 2625 m 5625 3300 l gs col-1 s gr +n 5655.00 3180.00 m 5625.00 3300.00 l 5595.00 3180.00 l 5625.50 3180.50 l 5655.00 3180.00 l clp gs 0.00 setgray ef gr gs col-1 s gr +% Polyline +n 5100 3300 m 6225 3300 l 6225 3750 l 5100 3750 l clp gs col-1 s gr +% Polyline + [1 50.0] 50.000000 setdash +n 2850 2400 m 2325 2400 l gs col-1 s gr [] 0 setdash +n 2445.00 2430.00 m 2325.00 2400.00 l 2445.00 2370.00 l 2445.50 2400.50 l 2445.00 2430.00 l clp gs 0.00 setgray ef gr gs col-1 s gr +% Polyline + [1 50.0] 50.000000 setdash +n 4125 2400 m 5100 2400 l gs col-1 s gr [] 0 setdash +n 4980.00 2370.00 m 5100.00 2400.00 l 4980.00 2430.00 l 4980.50 2400.50 l 4980.00 2370.00 l clp gs 0.00 setgray ef gr gs col-1 s gr +% Polyline +n 1050 3300 m 1950 3300 l 1950 3750 l 1050 3750 l clp gs col-1 s gr +/Times-Roman findfont 180.00 scalefont setfont +1200 1200 m +gs 1 -1 sc (config.in) col-1 show gr +/Times-Roman findfont 180.00 scalefont setfont +3000 1200 m +gs 1 -1 sc (configure) col-1 show gr +/Times-Roman findfont 180.00 scalefont setfont +3000 2400 m +gs 1 -1 sc (config.status) col-1 show gr +/Times-Roman findfont 180.00 scalefont setfont +1200 2400 m +gs 1 -1 sc (config.status) col-1 show gr +/Times-Roman findfont 180.00 scalefont setfont +1200 3600 m +gs 1 -1 sc (config.h) col-1 show gr +/Times-Roman findfont 180.00 scalefont setfont +5250 1200 m +gs 1 -1 sc (Makefile.in) col-1 show gr +/Times-Roman findfont 180.00 scalefont setfont +5250 2400 m +gs 1 -1 sc (config.status) col-1 show gr +/Times-Roman findfont 180.00 scalefont setfont +5250 3600 m +gs 1 -1 sc (Makefile) col-1 show gr +$F2psEnd +restore diff --git a/contrib/binutils/etc/configbuild.fig b/contrib/binutils/etc/configbuild.fig new file mode 100644 index 0000000..747592d --- /dev/null +++ b/contrib/binutils/etc/configbuild.fig @@ -0,0 +1,50 @@ +#FIG 3.1 +Portrait +Center +Inches +1200 2 +2 2 0 1 -1 7 0 0 -1 0.000 0 0 0 0 0 5 + 1050 900 2100 900 2100 1425 1050 1425 1050 900 +2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 1500 1425 1500 2100 +2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 1500 2625 1500 3300 +2 2 0 1 -1 7 0 0 -1 0.000 0 0 0 0 0 5 + 2925 900 3825 900 3825 1425 2925 1425 2925 900 +2 4 0 1 -1 7 0 0 -1 0.000 0 0 7 0 0 5 + 2325 2625 2325 2100 1050 2100 1050 2625 2325 2625 +2 2 0 1 -1 7 0 0 -1 0.000 0 0 0 0 0 5 + 2850 2100 4125 2100 4125 2625 2850 2625 2850 2100 +2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 3375 1425 3375 2100 +2 2 0 1 -1 7 0 0 -1 0.000 0 0 0 0 0 5 + 5100 900 6300 900 6300 1350 5100 1350 5100 900 +2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 5625 1350 5625 2100 +2 4 0 1 -1 7 0 0 -1 0.000 0 0 7 0 0 5 + 6375 2625 6375 2100 5100 2100 5100 2625 6375 2625 +2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 5625 2625 5625 3300 +2 2 0 1 -1 7 0 0 -1 0.000 0 0 0 0 0 5 + 5100 3300 6225 3300 6225 3750 5100 3750 5100 3300 +2 1 2 1 -1 7 0 0 -1 3.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 2850 2400 2325 2400 +2 1 2 1 -1 7 0 0 -1 3.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 4125 2400 5100 2400 +2 2 0 1 -1 7 0 0 -1 0.000 0 0 0 0 0 5 + 1050 3300 1950 3300 1950 3750 1050 3750 1050 3300 +4 0 -1 0 0 0 12 0.0000000 4 180 645 1200 1200 config.in\001 +4 0 -1 0 0 0 12 0.0000000 4 180 705 3000 1200 configure\001 +4 0 -1 0 0 0 12 0.0000000 4 180 990 3000 2400 config.status\001 +4 0 -1 0 0 0 12 0.0000000 4 180 990 1200 2400 config.status\001 +4 0 -1 0 0 0 12 0.0000000 4 180 600 1200 3600 config.h\001 +4 0 -1 0 0 0 12 0.0000000 4 135 855 5250 1200 Makefile.in\001 +4 0 -1 0 0 0 12 0.0000000 4 180 990 5250 2400 config.status\001 +4 0 -1 0 0 0 12 0.0000000 4 135 675 5250 3600 Makefile\001 diff --git a/contrib/binutils/etc/configbuild.jin b/contrib/binutils/etc/configbuild.jin Binary files differnew file mode 100644 index 0000000..44cd939 --- /dev/null +++ b/contrib/binutils/etc/configbuild.jin diff --git a/contrib/binutils/etc/configbuild.tin b/contrib/binutils/etc/configbuild.tin new file mode 100644 index 0000000..cfdd6fe --- /dev/null +++ b/contrib/binutils/etc/configbuild.tin @@ -0,0 +1,9 @@ + config.in *configure* Makefile.in + | | | + | v | + | config.status | + | | | + *config.status*<======+==========>*config.status* + | | + v v + config.h Makefile diff --git a/contrib/binutils/etc/configdev.ein b/contrib/binutils/etc/configdev.ein new file mode 100644 index 0000000..7f83785 --- /dev/null +++ b/contrib/binutils/etc/configdev.ein @@ -0,0 +1,185 @@ +%!PS-Adobe-2.0 EPSF-2.0 +%%Title: configdev.fig +%%Creator: fig2dev Version 3.1 Patchlevel 1 +%%CreationDate: Mon Jun 15 17:35:19 1998 +%%For: ian@tito.cygnus.com (Ian Lance Taylor) +%%Orientation: Portrait +%%BoundingBox: 0 0 344 317 +%%Pages: 0 +%%BeginSetup +%%IncludeFeature: *PageSize Letter +%%EndSetup +%%EndComments +/$F2psDict 200 dict def +$F2psDict begin +$F2psDict /mtrx matrix put +/col-1 {} def +/col0 {0.000 0.000 0.000 srgb} bind def +/col1 {0.000 0.000 1.000 srgb} bind def +/col2 {0.000 1.000 0.000 srgb} bind def +/col3 {0.000 1.000 1.000 srgb} bind def +/col4 {1.000 0.000 0.000 srgb} bind def +/col5 {1.000 0.000 1.000 srgb} bind def +/col6 {1.000 1.000 0.000 srgb} bind def +/col7 {1.000 1.000 1.000 srgb} bind def +/col8 {0.000 0.000 0.560 srgb} bind def +/col9 {0.000 0.000 0.690 srgb} bind def +/col10 {0.000 0.000 0.820 srgb} bind def +/col11 {0.530 0.810 1.000 srgb} bind def +/col12 {0.000 0.560 0.000 srgb} bind def +/col13 {0.000 0.690 0.000 srgb} bind def +/col14 {0.000 0.820 0.000 srgb} bind def +/col15 {0.000 0.560 0.560 srgb} bind def +/col16 {0.000 0.690 0.690 srgb} bind def +/col17 {0.000 0.820 0.820 srgb} bind def +/col18 {0.560 0.000 0.000 srgb} bind def +/col19 {0.690 0.000 0.000 srgb} bind def +/col20 {0.820 0.000 0.000 srgb} bind def +/col21 {0.560 0.000 0.560 srgb} bind def +/col22 {0.690 0.000 0.690 srgb} bind def +/col23 {0.820 0.000 0.820 srgb} bind def +/col24 {0.500 0.190 0.000 srgb} bind def +/col25 {0.630 0.250 0.000 srgb} bind def +/col26 {0.750 0.380 0.000 srgb} bind def +/col27 {1.000 0.500 0.500 srgb} bind def +/col28 {1.000 0.630 0.630 srgb} bind def +/col29 {1.000 0.750 0.750 srgb} bind def +/col30 {1.000 0.880 0.880 srgb} bind def +/col31 {1.000 0.840 0.000 srgb} bind def + +end +save +-62.0 370.0 translate +1 -1 scale + +/clp {closepath} bind def +/ef {eofill} bind def +/gr {grestore} bind def +/gs {gsave} bind def +/l {lineto} bind def +/m {moveto} bind def +/n {newpath} bind def +/s {stroke} bind def +/slc {setlinecap} bind def +/slj {setlinejoin} bind def +/slw {setlinewidth} bind def +/srgb {setrgbcolor} bind def +/rot {rotate} bind def +/sc {scale} bind def +/tr {translate} bind def +/tnt {dup dup currentrgbcolor + 4 -2 roll dup 1 exch sub 3 -1 roll mul add + 4 -2 roll dup 1 exch sub 3 -1 roll mul add + 4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb} + bind def +/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul + 4 -2 roll mul srgb} bind def +/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def +/$F2psEnd {$F2psEnteredState restore end} def +%%EndProlog + +$F2psBegin +10 setmiterlimit + 0.06000 0.06000 sc +7.500 slw +% Polyline +n 1050 900 m 2100 900 l 2100 1425 l 1050 1425 l clp gs col-1 s gr +% Polyline +n 2925 900 m 3975 900 l 3975 1425 l 2925 1425 l clp gs col-1 s gr +% Polyline +n 5550 900 m 6750 900 l 6750 1350 l 5550 1350 l clp gs col-1 s gr +% Polyline +n 3750 1800 m 5025 1800 l 5025 2250 l 3750 2250 l clp gs col-1 s gr +% Polyline +n 1155 2100 m 1050 2100 1050 2520 105 arcto 4 {pop} repeat 1050 2625 2070 2625 105 arcto 4 {pop} repeat 2175 2625 2175 2205 105 arcto 4 {pop} repeat 2175 2100 1155 2100 105 arcto 4 {pop} repeat clp gs col-1 s gr +% Polyline +n 5550 3300 m 6675 3300 l 6675 3750 l 5550 3750 l clp gs col-1 s gr +% Polyline +n 5655 2100 m 5550 2100 5550 2520 105 arcto 4 {pop} repeat 5550 2625 6495 2625 105 arcto 4 {pop} repeat 6600 2625 6600 2205 105 arcto 4 {pop} repeat 6600 2100 5655 2100 105 arcto 4 {pop} repeat clp gs col-1 s gr +% Polyline +n 3750 3600 m 4875 3600 l 4875 4050 l 3750 4050 l clp gs col-1 s gr +% Polyline +n 3855 2700 m 3750 2700 3750 3045 105 arcto 4 {pop} repeat 3750 3150 4545 3150 105 arcto 4 {pop} repeat 4650 3150 4650 2805 105 arcto 4 {pop} repeat 4650 2700 3855 2700 105 arcto 4 {pop} repeat clp gs col-1 s gr +% Polyline +n 2850 5700 m 3750 5700 l 3750 6150 l 2850 6150 l clp gs col-1 s gr +% Polyline +n 3030 4800 m 2925 4800 2925 5145 105 arcto 4 {pop} repeat 2925 5250 3645 5250 105 arcto 4 {pop} repeat 3750 5250 3750 4905 105 arcto 4 {pop} repeat 3750 4800 3030 4800 105 arcto 4 {pop} repeat clp gs col-1 s gr +% Polyline +n 1500 1425 m 1500 2100 l gs col-1 s gr +n 1530.00 1980.00 m 1500.00 2100.00 l 1470.00 1980.00 l 1500.50 1980.50 l 1530.00 1980.00 l clp gs 0.00 setgray ef gr gs col-1 s gr +% Polyline +n 3300 1425 m 3300 4800 l gs col-1 s gr +n 3330.00 4680.00 m 3300.00 4800.00 l 3270.00 4680.00 l 3300.50 4680.50 l 3330.00 4680.00 l clp gs 0.00 setgray ef gr gs col-1 s gr +% Polyline +n 3300 1575 m 1875 1575 l 1875 2100 l gs col-1 s gr +n 1905.00 1980.00 m 1875.00 2100.00 l 1845.00 1980.00 l 1875.50 1980.50 l 1905.00 1980.00 l clp gs 0.00 setgray ef gr gs col-1 s gr +% Polyline +n 3300 1575 m 5700 1575 l 5700 2100 l gs col-1 s gr +n 5730.00 1980.00 m 5700.00 2100.00 l 5670.00 1980.00 l 5700.50 1980.50 l 5730.00 1980.00 l clp gs 0.00 setgray ef gr gs col-1 s gr +% Polyline +n 6225 1350 m 6225 2100 l gs col-1 s gr +n 6255.00 1980.00 m 6225.00 2100.00 l 6195.00 1980.00 l 6225.50 1980.50 l 6255.00 1980.00 l clp gs 0.00 setgray ef gr gs col-1 s gr +% Polyline +n 6075 2625 m 6075 3300 l gs col-1 s gr +n 6105.00 3180.00 m 6075.00 3300.00 l 6045.00 3180.00 l 6075.50 3180.50 l 6105.00 3180.00 l clp gs 0.00 setgray ef gr gs col-1 s gr +% Polyline +n 4200 2250 m 4200 2700 l gs col-1 s gr +n 4230.00 2580.00 m 4200.00 2700.00 l 4170.00 2580.00 l 4200.50 2580.50 l 4230.00 2580.00 l clp gs 0.00 setgray ef gr gs col-1 s gr +% Polyline +n 4200 3150 m 4200 3600 l gs col-1 s gr +n 4230.00 3480.00 m 4200.00 3600.00 l 4170.00 3480.00 l 4200.50 3480.50 l 4230.00 3480.00 l clp gs 0.00 setgray ef gr gs col-1 s gr +% Polyline +n 4200 4050 m 4200 4500 l 3675 4500 l 3675 4800 l gs col-1 s gr +n 3705.00 4680.00 m 3675.00 4800.00 l 3645.00 4680.00 l 3675.50 4680.50 l 3705.00 4680.00 l clp gs 0.00 setgray ef gr gs col-1 s gr +% Polyline +n 3375 5250 m 3375 5700 l gs col-1 s gr +n 3405.00 5580.00 m 3375.00 5700.00 l 3345.00 5580.00 l 3375.50 5580.50 l 3405.00 5580.00 l clp gs 0.00 setgray ef gr gs col-1 s gr +% Polyline +n 3300 2925 m 3750 2925 l gs col-1 s gr +n 3630.00 2895.00 m 3750.00 2925.00 l 3630.00 2955.00 l 3630.50 2925.50 l 3630.00 2895.00 l clp gs 0.00 setgray ef gr gs col-1 s gr +% Polyline +n 1500 2625 m 1500 3300 l gs col-1 s gr +n 1530.00 3180.00 m 1500.00 3300.00 l 1470.00 3180.00 l 1500.50 3180.50 l 1530.00 3180.00 l clp gs 0.00 setgray ef gr gs col-1 s gr +% Polyline +n 1050 3300 m 2100 3300 l 2100 3750 l 1050 3750 l clp gs col-1 s gr +% Polyline +n 4875 3825 m 5250 3825 l 5250 2400 l 5550 2400 l gs col-1 s gr +n 5430.00 2370.00 m 5550.00 2400.00 l 5430.00 2430.00 l 5430.50 2400.50 l 5430.00 2370.00 l clp gs 0.00 setgray ef gr gs col-1 s gr +/Times-Roman findfont 180.00 scalefont setfont +1200 1200 m +gs 1 -1 sc (acconfig.h) col-1 show gr +/Times-Roman findfont 180.00 scalefont setfont +3000 1200 m +gs 1 -1 sc (configure.in) col-1 show gr +/Times-Roman findfont 180.00 scalefont setfont +5700 1200 m +gs 1 -1 sc (Makefile.am) col-1 show gr +/Times-Roman findfont 180.00 scalefont setfont +3900 2100 m +gs 1 -1 sc (acinclude.m4) col-1 show gr +/Times-Roman findfont 180.00 scalefont setfont +1200 2400 m +gs 1 -1 sc (autoheader) col-1 show gr +/Times-Roman findfont 180.00 scalefont setfont +1200 3600 m +gs 1 -1 sc (config.in) col-1 show gr +/Times-Roman findfont 180.00 scalefont setfont +5700 3600 m +gs 1 -1 sc (Makefile.in) col-1 show gr +/Times-Roman findfont 180.00 scalefont setfont +5700 2400 m +gs 1 -1 sc (automake) col-1 show gr +/Times-Roman findfont 180.00 scalefont setfont +3900 3900 m +gs 1 -1 sc (aclocal.m4) col-1 show gr +/Times-Roman findfont 180.00 scalefont setfont +3900 3000 m +gs 1 -1 sc (aclocal) col-1 show gr +/Times-Roman findfont 180.00 scalefont setfont +3000 6000 m +gs 1 -1 sc (configure) col-1 show gr +/Times-Roman findfont 180.00 scalefont setfont +3000 5100 m +gs 1 -1 sc (autoconf) col-1 show gr +$F2psEnd +restore diff --git a/contrib/binutils/etc/configdev.fig b/contrib/binutils/etc/configdev.fig new file mode 100644 index 0000000..4d386ec --- /dev/null +++ b/contrib/binutils/etc/configdev.fig @@ -0,0 +1,80 @@ +#FIG 3.1 +Portrait +Center +Inches +1200 2 +2 2 0 1 -1 7 0 0 -1 0.000 0 0 0 0 0 5 + 1050 900 2100 900 2100 1425 1050 1425 1050 900 +2 2 0 1 -1 7 0 0 -1 0.000 0 0 0 0 0 5 + 2925 900 3975 900 3975 1425 2925 1425 2925 900 +2 2 0 1 -1 7 0 0 -1 0.000 0 0 0 0 0 5 + 5550 900 6750 900 6750 1350 5550 1350 5550 900 +2 2 0 1 -1 7 0 0 -1 0.000 0 0 0 0 0 5 + 3750 1800 5025 1800 5025 2250 3750 2250 3750 1800 +2 4 0 1 -1 7 0 0 -1 0.000 0 0 7 0 0 5 + 2175 2625 2175 2100 1050 2100 1050 2625 2175 2625 +2 2 0 1 -1 7 0 0 -1 0.000 0 0 0 0 0 5 + 5550 3300 6675 3300 6675 3750 5550 3750 5550 3300 +2 4 0 1 -1 7 0 0 -1 0.000 0 0 7 0 0 5 + 6600 2625 6600 2100 5550 2100 5550 2625 6600 2625 +2 2 0 1 -1 7 0 0 -1 0.000 0 0 0 0 0 5 + 3750 3600 4875 3600 4875 4050 3750 4050 3750 3600 +2 4 0 1 -1 7 0 0 -1 0.000 0 0 7 0 0 5 + 4650 3150 4650 2700 3750 2700 3750 3150 4650 3150 +2 2 0 1 -1 7 0 0 -1 0.000 0 0 0 0 0 5 + 2850 5700 3750 5700 3750 6150 2850 6150 2850 5700 +2 4 0 1 -1 7 0 0 -1 0.000 0 0 7 0 0 5 + 3750 5250 3750 4800 2925 4800 2925 5250 3750 5250 +2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 1500 1425 1500 2100 +2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 3300 1425 3300 4800 +2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 3 + 1 1 1.00 60.00 120.00 + 3300 1575 1875 1575 1875 2100 +2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 3 + 1 1 1.00 60.00 120.00 + 3300 1575 5700 1575 5700 2100 +2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 6225 1350 6225 2100 +2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 6075 2625 6075 3300 +2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 4200 2250 4200 2700 +2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 4200 3150 4200 3600 +2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 4 + 1 1 1.00 60.00 120.00 + 4200 4050 4200 4500 3675 4500 3675 4800 +2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 3375 5250 3375 5700 +2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 3300 2925 3750 2925 +2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 1500 2625 1500 3300 +2 2 0 1 -1 7 0 0 -1 0.000 0 0 0 0 0 5 + 1050 3300 2100 3300 2100 3750 1050 3750 1050 3300 +2 1 0 1 -1 7 0 0 -1 0.000 0 0 -1 1 0 4 + 1 1 1.00 60.00 120.00 + 4875 3825 5250 3825 5250 2400 5550 2400 +4 0 -1 0 0 0 12 0.0000000 4 180 780 1200 1200 acconfig.h\001 +4 0 -1 0 0 0 12 0.0000000 4 180 885 3000 1200 configure.in\001 +4 0 -1 0 0 0 12 0.0000000 4 135 945 5700 1200 Makefile.am\001 +4 0 -1 0 0 0 12 0.0000000 4 135 990 3900 2100 acinclude.m4\001 +4 0 -1 0 0 0 12 0.0000000 4 135 840 1200 2400 autoheader\001 +4 0 -1 0 0 0 12 0.0000000 4 180 645 1200 3600 config.in\001 +4 0 -1 0 0 0 12 0.0000000 4 135 855 5700 3600 Makefile.in\001 +4 0 -1 0 0 0 12 0.0000000 4 135 735 5700 2400 automake\001 +4 0 -1 0 0 0 12 0.0000000 4 135 810 3900 3900 aclocal.m4\001 +4 0 -1 0 0 0 12 0.0000000 4 135 540 3900 3000 aclocal\001 +4 0 -1 0 0 0 12 0.0000000 4 180 705 3000 6000 configure\001 +4 0 -1 0 0 0 12 0.0000000 4 135 660 3000 5100 autoconf\001 diff --git a/contrib/binutils/etc/configdev.jin b/contrib/binutils/etc/configdev.jin Binary files differnew file mode 100644 index 0000000..9b11a71 --- /dev/null +++ b/contrib/binutils/etc/configdev.jin diff --git a/contrib/binutils/etc/configdev.tin b/contrib/binutils/etc/configdev.tin new file mode 100644 index 0000000..c9b6f34 --- /dev/null +++ b/contrib/binutils/etc/configdev.tin @@ -0,0 +1,17 @@ + acconfig.h configure.in Makefile.am + | | | + | --------------+---------------------- | + | | | | | + v v | acinclude.m4 | | + *autoheader* | | v v + | | v --->*automake* + v |--->*aclocal* | | + config.in | | | v + | v | Makefile.in + | aclocal.m4--- + | | + v v + *autoconf* + | + v + configure diff --git a/contrib/binutils/etc/configure.texi b/contrib/binutils/etc/configure.texi index 4457774..9140167 100644 --- a/contrib/binutils/etc/configure.texi +++ b/contrib/binutils/etc/configure.texi @@ -1,23 +1,20 @@ -\input texinfo @c -*-texinfo-*- +\input texinfo +@c %**start of header @setfilename configure.info -@settitle Cygnus configure +@settitle The GNU configure and build system +@setchapternewpage off +@c %**end of header -@synindex ky cp - -@setchapternewpage odd +@dircategory GNU admin +@direntry +* configure: (configure). The GNU configure and build system +@end direntry @ifinfo -@format -START-INFO-DIR-ENTRY -* configure: (configure). Cygnus configure. -END-INFO-DIR-ENTRY -@end format -@end ifinfo +This file documents the GNU configure and build system. -@ifinfo -This document describes the Cygnus Support version of @code{configure}. +Copyright (C) 1998 Cygnus Solutions. -Copyright (C) 1991, 1992, 1993 Cygnus Support 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. @@ -26,9 +23,9 @@ are preserved on all copies. 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 -(this paragraph not being relevant to the printed manual). -@end ignore + +@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 @@ -37,23 +34,16 @@ 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 Cygnus Support. +by the Foundation. @end ifinfo -@c We should not distribute texinfo files with smallbook enabled. -@c @smallbook -@finalout @titlepage -@title Cygnus configure -@author K. Richard Pixley -@author Cygnus Support -@page -@cindex copyleft +@title The GNU configure and build system +@author Ian Lance Taylor +@page @vskip 0pt plus 1filll -Edited January, 1993, by Jeffrey Osier, Cygnus Support. - -Copyright @copyright{} 1991, 1992, 1993 Cygnus Support +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 @@ -66,1765 +56,2589 @@ 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 Cygnus Support. +except that this permission notice may be stated in a translation +approved by the Free Software Foundation. @end titlepage -@c --------------------------------------------------------------------- @ifinfo @node Top -@top Cygnus configure +@top GNU configure and build system -This file documents the configuration system used and distributed by -Cygnus Support. +The GNU configure and build system. @menu -* What configure does:: What configure does -* Invoking configure:: Invoking configure---basic usage -* Using configure:: More than you ever wanted to know -* Porting:: How to use configure with new programs -* Variables Index:: -* Concept Index:: +* 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 -@c --------------------------------------------------------------------- -@node What configure does -@chapter What @code{configure} does -@cindex Introduction -@cindex Overview -@cindex What @code{configure} does -@kindex Cygnus Support Developer's Kit - -This manual documents Cygnus @code{configure}, a program which helps to -automate much of the setup activity associated with building large suites of -programs, such the Cygnus Support Developer's Kit. This manual is therefore -geared toward readers who are likely to face the problem of configuring -software in source form before compiling and installing it. We assume you are -an experienced programmer or system administrator. -@ifinfo -For further background on this topic, see @ref{Some Basic Terms, , Apologia -Configure, cfg-paper, On Configuring Development Tools}, by K. Richard -Pixley. @end ifinfo -@iftex -For further background on this topic, see @cite{On Configuring Development -Tools} by K. Richard Pixley. -@end iftex - -When @code{configure} runs, it does the following things: - -@table @emph -@item @bullet{} creates build directories -@vindex srcdir -@cindex @code{srcdir} -@cindex Build directories -When you run @code{configure} with the @samp{--srcdir} option, it uses the -current directory as the @dfn{build directory}, creating under it a directory -tree that parallels the directory structure of the source directory. If you -don't specify a @samp{srcdir}, @code{configure} first assumes that the source -code you wish to configure is in your current directory; if it finds no -@file{configure.in} input file there, it searches in the directory -@code{configure} itself lies in. (For details, see @ref{Build directories, , -Build directories}.) - -@item @bullet{} generates @file{Makefile} -@cindex @code{Makefile} generation -A @file{Makefile} template from the source directory, usually called -@file{Makefile.in}, is copied to an output file in the build directory which is -most often named @file{Makefile}. @code{configure} places definitions for a -number of standard @file{Makefile} macros at the beginning of the output file. -If @w{@samp{--prefix=@var{dir}}} or @w{@samp{--exec_prefix=@var{dir}}} are -specified on the @code{configure} command line, corresponding @file{Makefile} -variables are set accordingly. If host, target, or site-specific -@file{Makefile} fragments exist, these are inserted into the output file. (For -details, see @ref{Makefile generation, , @code{Makefile} generation}.) - -@item @bullet{} generates @file{.gdbinit} -@cindex @code{.gdbinit} -If the source directory contains a @file{.gdbinit} file and the build directory -is not the same as the source directory, a @file{.gdbinit} file is created in -the build directory. This @file{.gdbinit} file contains commands which allow -the source directory to be read when debugging with the @sc{gnu} debugger, -@code{gdb}. (@xref{Command Files, , Command Files, gdb, Debugging With GDB}.) - -@item @bullet{} makes symbolic links -@cindex Symbolic links -Most build directories require that some symbolic links with generic names are -built pointing to specific files in the source directory. If the system where -@code{configure} runs cannot support symbolic links, hard links are used -instead. (For details, see @ref{configure.in, , The @code{configure.in} input -file}.) - -@item @bullet{} generates @file{config.status} -@cindex @code{config.status} -@code{configure} creates a shell script named @file{config.status} in the build -directory. This shell script, when run from the build directory (usually from -within a @file{Makefile}), will reconfigure the build directory (but not its -subdirectories). This is most often used to have a @file{Makefile} update -itself automatically if a new source directory is available. - -@item @bullet{} calls itself recursively -@cindex Recursion -If the source directory has subdirectories that should also be configured, -@code{configure} is called for each. + +@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 -@c --------------------------------------------------------------------- -@node Invoking configure -@chapter Invoking @code{configure} -@cindex Invoking @code{configure} -@cindex Usage +@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. -Cygnus @code{configure} is a shell script which resides in a source tree. The -usual way to invoke @code{configure} is from the shell, as follows: +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. -@cindex Example session +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 -eg$ ./configure @var{hosttype} +AM_CONFIG_HEADER(config.h:config.in) @end example -@noindent -This prepares the source in the current directory (@file{.}) to be -compiled for a @var{hosttype} environment. It assumes that you wish to -build programs and files in the default @dfn{build directory} (also the -current directory, @file{.}). If you do not specify a value for -@var{hosttype}, Cygnus @code{configure} will attempt to discover this -information by itself (@pxref{config.guess, , Determining system -information}). For information on @var{hosttype} environments, -@xref{Host, , Host}. - -All @sc{gnu} software is packaged with one or more @code{configure} script(s) -(@pxref{Configuration, , How Configuration Should Work, standards, GNU Coding -Standards}). By using @code{configure} you prepare the source for your -specific environment by selecting and using @file{Makefile} fragments and -fragments of shell scripts, which are prepared in advance and stored with the -source. - -@code{configure}'s command-line options also allow you to specify other aspects -of the source configuration: +@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 - configure @var{hosttype} [--target=@var{target}] [--srcdir=@var{dir}] [--rm] - [--site=@var{site}] [--prefix=@var{dir}] [--exec-prefix=@var{dir}] - [--program-prefix=@var{string}] [--tmpdir=@var{dir}] - [--with-@var{package}[=@var{yes/no}]] [--without-@var{package}] - [--enable-@var{feature}[=@var{yes/no}]] [--disable-@var{feature}] - [--norecursion] [--nfp] [-s] [-v] [-V | --version] [--help] +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}. -@table @code -@item --target=@var{target} -@cindex @code{--target} -@cindex @code{target} option -@vindex target -Requests that the sources be configured to target the @var{target} machine. If -no target is specified explicitly, the target is assumed to be the same as the -host (i.e., a @dfn{native} configuration). @xref{Host, , Host}, and -@ref{Target, , Target}, for -discussions of each. - -@item --srcdir=@var{dir} -@cindex @code{--srcdir} -@cindex @code{srcdir} option -@vindex srcdir -Direct each generated @file{Makefile} to use the sources located in directory -@var{dir}. Use this option whenever you wish the object code to reside in a -different place from the source code. The @dfn{build directory} is always -assumed to be the directory you call @code{configure} from. See @ref{Build -directories, , Build directories}, for an example. If the source directory is -not specified, @code{configure} assumes that the source is in your current -directory. If @code{configure} finds no @file{configure.in} there, it searches -in the same directory that the @code{configure} script itself lies in. -Pathnames specified (Values for @var{dir}) can be either absolute relative to -the @emph{build} directory. - -@item --rm -@cindex @code{--rm} -@cindex @code{rm} option -@vindex rm -@emph{Remove} the configuration specified by @var{hosttype} and the other -command-line options, rather than create it. - -@c FIXME: check @ref -@quotation -@emph{Note:} We recommend that you use @samp{make distclean} rather than -use this option; see @ref{Invoking make,,Invoking @code{make},make,GNU -Make}, for details on @samp{make distclean}. -@end quotation - -@item --site=@var{site} -@cindex @code{--site} -@cindex @code{site} option -@vindex site -Generate the @file{Makefile} using site-specific @file{Makefile} fragments for -@var{site}. @xref{Makefile fragments, , Adding information about local -conventions}. - -@item --prefix=@var{dir} -@cindex @code{--prefix} -@cindex @code{prefix} option -@vindex prefix -Configure the source to install programs and files under directory @var{dir}. - -This option sets the variable @samp{prefix}. Each generated @file{Makefile} -will have its @samp{prefix} variables set to this value. (@xref{What configure -really does, , What @code{configure} really does}.) - -@item --exec-prefix=@var{dir} -@cindex @code{--exec-prefix} -@cindex @code{exec-prefix} option -@vindex exec-prefix -Configure the source to install @dfn{host dependent} files in @var{dir}. - -This option sets the variable @samp{exec_prefix}. Each generated -@file{Makefile} will have its @samp{exec_prefix} variables set to this value. -(@xref{What configure really does, , What @code{configure} really does}.) - -@item --program-prefix=@var{string} -@cindex @code{--program-prefix} -@cindex @code{program-prefix} option -@vindex program-prefix -Configure the source to install certain programs using @var{string} as a -prefix. This applies to programs which might be used for cross-compilation, -such as the compiler and the binary utilities, and also to programs which have -the same names as common Unix programs, such as @code{make}. - -This option sets the variable @samp{program_prefix}. Each generated -@file{Makefile} will have its @samp{program_prefix} variables set to this -value. (@xref{What configure really does, , What @code{configure} really -does}.) - -@item --tmpdir=@var{tmpdir} -@cindex @code{--tmpdir} -@cindex @code{tmpdir} option -@vindex tmpdir -Use the directory @var{tmpdir} for @code{configure}'s temporary files. The -default is the value of the environment variable @w{@code{TMPDIR}}, or -@file{/tmp} if the environment variable is not set. - -@item --with-@var{package}[=@var{yes/no}] -@itemx --without-@var{package} -@cindex @code{--with-@var{package}} -@cindex @code{with-@var{package}} option -@vindex with-@var{package} -@cindex @code{--without-@var{package}} -@cindex @code{without-@var{package}} option -@vindex without-@var{package} -Indicate that @var{package} is present, or not present, depending on -@var{yes/no}. If @var{yes/no} is nonexistent, its value is assumed to be -@code{yes}. @samp{--without-@var{package}} is equivalent to -@samp{--with-@var{package}=no}. - -For example, if you wish to configure the program @code{gcc} for a Sun -SPARCstation running SunOS 4.x, and you want @code{gcc} to use the -@sc{gnu} linker @code{ld}, you can configure @code{gcc} using - -@cindex Example session +Every @file{Makefile.am} written at Cygnus should contain the line @smallexample -eg$ configure --with-gnu-ld sun4 +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 -@xref{What configure really does, , What @code{configure} really does}, for -details. See the installation or release notes for your particular package for -details on which other @var{package} options are recognized. -@c FIXME - need to include info about --with-* in other dox! - -@item --enable-@var{feature}[=@var{yes/no}] -@itemx --disable-@var{feature} -@cindex @code{--enable-@var{feature}} -@cindex @code{enable-@var{feature}} option -@vindex enable-@var{feature} -@cindex @code{--disable-@var{feature}} -@cindex @code{disable-@var{feature}} option -@vindex disable-@var{feature} -Include @var{feature}, or not, depending on @var{yes/no}. If @var{yes/no} is -nonexistent, its value is assumed to be @code{yes}. -@samp{--disable-@var{feature}} is equivalent to -@samp{--enable-@var{feature}=no}. +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 -@xref{What configure really does, , What @code{configure} really does}, for -details. See the installation or release notes for your particular package for -details on which other @var{feature} options are recognized. -@c FIXME - need to include info about --enable-* in other dox! - -@item --norecursion -@cindex @code{--norecursion} -@cindex @code{norecursion} option -@vindex norecursion -Configure only this directory; ignore any subdirectories. This is used by the -executable shell script @file{config.status} to reconfigure only the current -directory; it is most often used non-interactively, when @code{make} is -invoked. (@xref{config.status, , @code{config.status}}.) - -@item --nfp -@cindex @code{--nfp} -@cindex @code{nfp} option -@vindex nfp -Assume that the intended @var{hosttype} has no floating point unit. - -@item -s -@cindex @code{-s} -@cindex @code{s} option -Suppress status output. This option is used internally by -@code{configure} when calling itself recursively in subdirectories. You -can override this option with the @code{--verbose} option. - -@item -v -@itemx --verbose -@cindex @code{-v} -@cindex @code{--verbose} -@cindex @code{v} option -@cindex @code{verbose} option -@cindex Verbose Output -@vindex verbose -Print status lines for each directory configured. Normally, only the -status lines for the initial working directory are printed. - -@item --version -@itemx -V -@cindex version -@cindex @code{--version} -@cindex version -Print the @code{configure} version number. - -@item --help -@cindex Usage -@cindex @code{--help} -@cindex @code{help} option -Print a short summary of how to invoke @code{configure}. -@end table +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}). -@cindex Abbreviating option names -@cindex Truncating option names -@cartouche -@emph{Note:} You may introduce options with a single dash, @samp{-}, rather -than two dashes, @samp{--}. However, you may not be able to truncate long -option names when using a single dash. When using two dashes, options may be -abbreviated as long as each option can be uniquely identified. For example, +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 -eg$ configure --s=/u/me/src @var{hosttype} +lib_LIBRARIES = lib@var{name}.a @end smallexample @noindent -is ambiguous, as @w{@samp{--s}} could refer to either @w{@samp{--site}} or -@w{@samp{--srcdir}}. However, +where @samp{lib@var{name}.a} is the name of the library. You will then +want a line like @smallexample -eg$ configure --src=/u/me/src @var{hosttype} +lib@var{name}_a_SOURCES = @var{file} @var{file} @dots{} @end smallexample @noindent -is a valid abbreviation. -@end cartouche +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 -@c ======================================================================== -@node Using configure -@chapter Using @code{configure} -@cindex Using @code{configure} -@cindex Detailed usage -@cindex Usage: detailed +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. -@code{configure} prepares source directories for building programs in -them. ``Configuring'' is the process of preparing software to compile -correctly on a given @dfn{host}, for a given @dfn{target}. +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. -@code{configure} subsequently writes a configured @file{Makefile} from a -pre-built template; @code{configure} uses variables that have been set in the -configuring process to determine the values of some variables in the -@file{Makefile}. Because of this we will refer to both @code{configure} -variables and @file{Makefile} variables. This convention allows us to -determine where the variable should be set initially, in either -@file{configure.in} or @file{Makefile.in}. +See the automake manual for more information. -@menu -* What configure really does:: What configure really does -* configure.in:: The configure.in input file -* Install locations:: Where to install things once they are built -* Host:: Telling configure what will source will be built -* Target:: Telling configure what the source will target -* Makefile fragments:: Adding information about local conventions -* Makefile extensions:: Extensions to the GNU coding standards -@end menu +@node Write acconfig.h +@section Write acconfig.h +@cindex @file{acconfig.h}, writing -@c --------------------------------------------------------------------- -@node What configure really does -@section What @code{configure} really does -@cindex What @code{configure} really does -@cindex Behind the scenes -@cindex @code{configure} back end -@cindex @code{configure} details +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. -Cygnus @code{configure} is a shell script that sets up an environment in -which your programs will compile correctly for your machine and -operating system, and will install in proper places. @code{configure} -accomplishes this task by doing the following: +@smallexample +/* Name of package. */ +#undef PACKAGE -@itemize @bullet -@item -it generates a @file{Makefile} from a custom template called -@file{Makefile.in} in each relevant source directory; +/* Version of package. */ +#undef VERSION +@end smallexample -@item -it customizes the build process to your specifications; you set certain -variables for @code{configure}, either on the command line or in the -file @file{configure.in}, which subsequently sets variables in each -generated @file{Makefile} to be used by @code{make} when actually -building the software; +This requirement is really a bug in the system, and the requirement may +be eliminated at some later date. -@item -it creates @dfn{build directories}, places for your code to be compiled -in before being installed; +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. -@item -it generates a @file{.gdbinit} in the build directory, if needed, to -communicate to @code{gdb} where to find the program's source code; +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 -@item -it generates a shell script called @file{config.status} -which is used most often by the @file{Makefile} to reconfigure itself; +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. -@item -it recurses in subdirectories, setting up entire trees so that they build -correctly; if @code{configure} finds another @code{configure} script -further down in a given source tree, it knows to use this script and not -recur. -@end itemize +(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). -For the sake of safety (i.e., in order to prevent broken installations), the -@sc{gnu} coding standards call for software to be @dfn{configured} in such a -way that an end user trying to build a given package will be able to do so by -affecting a finite number of variables. All @sc{gnu} software comes with an -executable @code{configure} shell script which sets up an environment within a -build directory which will correctly compile your new package for your host -(or, alternatively, whatever host you specify to @code{configure}). -@ifinfo -For further background on this topic, see @ref{Some Basic Terms, , Apologia -Configure, cfg-paper, On Configuring Development Tools}, by K. Richard -Pixley. -@end ifinfo -@iftex -For further background on this topic, see @cite{On Configuring Development -Tools} by K. Richard Pixley. -@end iftex +@node Generate files +@section Generate files -Use @code{configure} to set for the build process: +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. -@itemize @bullet -@item -correct values for certain variables; +@smallexample +aclocal +autoconf +autoheader +automake +@end smallexample -@item -which type of host you wish to configure a given package for -(@pxref{Host, , Host}); +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. -@item -where you want to install this package (by using @samp{prefix}, -@samp{exec-prefix} and @samp{program-prefix}; @pxref{Install details, , -Full descriptions of all installation directories}); +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}. -@item -optionally, which type of machine you wish to @dfn{target} this -package's output to (@pxref{Target, , Target}); +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. -@item -which other @sc{gnu} packages are already installed and available to -this particular build (by using the @samp{--with-@var{package}} option; -@pxref{Invoking configure, , Invoking @code{configure}}); +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. -@item -where to place temporary files (by using the @samp{--tmpdir=@var{dir}} -option; @pxref{Invoking configure, , Invoking @code{configure}}); +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. -@item whether to recur in subdirectories (changeable through the -@w{@samp{--norecursion}} option; @pxref{Invoking configure, , Invoking -@code{configure}}). -@end itemize +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. -@code{configure} uses a few other files to complete its tasks. These are -discussed in detail where noted. +@node Getting Started Example +@section Example -@table @code -@cindex Other files -@item configure.in -@cindex @code{configure.in} definition -Input file for @code{configure}. Shell script fragments reside here. -@xref{configure.in, , The @code{configure.in} input file}. +Let's consider a trivial example. -@item Makefile.in -@cindex @code{Makefile.in} definition -Template which @code{configure} uses to build a file called @file{Makefile} in -the @dfn{build directory}. @xref{Makefile generation, , @code{Makefile} -generation}. +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. -@item config.sub -@cindex @code{config.sub} definition -Shell script used by @code{configure} to expand referents to the -@var{hosttype} argument into a single specification of the form -@w{@var{cpu-vendor-os}}. For instance, on the command line you can -specify +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. -@cindex Example session @example -eg$ ./configure sun4 +#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 -@noindent -to configure for a Sun SPARCstation running SunOS 4.x. @code{configure} -consults @code{config.sub} to find that the three-part specification for this -is +We also write a simple @file{Makefile}. @example -sparc-sun-sunos4.1.1 +CC = gcc +CFLAGS = -g -O2 + +all: poke + +poke: poke.o + $(CC) -o poke $(CFLAGS) $(LDFLAGS) poke.o @end example -@noindent -which notes the @var{cpu} as @samp{sparc}, the @var{manufacturer} as @samp{sun} -(Sun Microsystems), and the @var{os} (operating system) as @samp{sunos4.1.1}, -the SunOS 4.1.1 release. @xref{configure variables, , Variables available to @code{configure}}. +So far, so good. -@item config.guess -@cindex @code{config.guess} definition -If you do not put the @var{hosttype} argument on the command line, -@code{configure} uses the @code{config.guess} shell script to make an -analysis of your machine (it assumes that you wish to configure your -software for the type of machine on which you are running). The output -of @code{config.guess} is a three-part identifier as described above. +Unfortunately, there are a few problems. -@item config.status -@cindex @code{config.status} definition -The final step in configuring a directory is to create a shell script, -@code{config.status}. The main purpose of this file is to allow the -@file{Makefile} for the current directory to rebuild itself, if -necessary. @xref{config.status, , @code{config.status}}. - -@item config/* -@cindex @code{config/} subdirectory -@code{configure} uses three types of @file{Makefile} @dfn{fragments}, which -reside in the directory @file{@var{srcdir}/config/}. @xref{Makefile fragments, -, Adding information about local conventions}. -@end table +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. -@menu -* Build variables:: Variable-spaghetti made simple -* Build directories:: Build directories described well -* Makefile generation:: To build a Makefile -* config.guess:: Be vewwy quiet, I'm hunting system information -* config.status:: To rebuild a Makefile -@end menu +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). -@c --------------------------------------------------------------------- -@node Build variables -@subsection Build variables -@cindex Build variables -@cindex Cygnus Support Developer's Kit -@cindex Variables - -There are several variables in the build process which you can control through -build programs such as @code{make}. These include machine definitions, local -conventions, installation locations, locations for temporary files, etc. This -data is accessible through certain variables which are configurable in the -build process; we refer to them as @dfn{build variables}. - -For lists of build variables which you can affect by using @code{configure}, -see @ref{configure variables, , Variables available to @code{configure.in}}, -and @ref{Install details, , Full descriptions of all installation directories}. - -Generally, build variables, which are used by the @file{Makefile} to -determine various aspects of the build and installation processes, are -changeable with command-line options to @code{configure}. In most large -suites of programs, like the Cygnus Support Developer's Kit, the -individual programs reside in several subdirectories of a single source -code ``tree''. All of these subdirectories need to be configured with -information relative to the @dfn{build directory}, which is not known -until @code{configure} is run. Unless specified otherwise, -@code{configure} recursively configures every subdirectory in the source -tree. - -Build variables are passed from @code{configure} directly into the -@file{Makefile}, and use the same names (except that dashes are -transformed into underbars; for example, when you specify the option -@samp{--exec-prefix} on the command line, the @file{Makefile} variable -@samp{exec_prefix} is set). In other words, if you specify - -@cindex Example session @example -eg$ ./configure --prefix=/usr/gnu/local @dots{} @var{hosttype} +#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 -@noindent -on the command line, @code{configure} sets an variable called @samp{prefix} to -@samp{/usr/gnu/local}, and passes this into the @file{Makefile} in the same -manner. After this command, each @file{Makefile} generated by @code{configure} -will contain a line that reads: +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 -prefix = /usr/gnu/local +# 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 -For a list of the @file{Makefile} variables @code{configure} can change, and -instructions on how to change them, see @ref{configure variables, , Variables -available to @code{configure.in}}, and @ref{Invoking configure, , Invoking -@code{configure}}. - -@c --------------------------------------------------------------------- -@node Build directories -@subsection Build directories -@cindex Build directories -@cindex Object directories -@cindex Building for multiple hosts -@cindex Building for multiple targets - -By default, @code{configure} builds a @file{Makefile} and symbolic links in the -same directory as the source files. This default works for many cases, but it -has limitations. For instance, using this approach, you can only build object -code for one host at a time. - -We refer to each directory where @code{configure} builds a @file{Makefile} as -a @dfn{build directory}. - -The build directory for any given build is always the directory from which you -call @code{configure}, or @file{.} relative to your prompt. The default -@dfn{source directory}, the place @code{configure} looks to find source code, -is also @file{.}. For instance, if we have a directory @file{/gnu-stuff/src/} -that is the top branch of a tree of @sc{gnu} source code we wish to configure, -then the program we will use to configure this code is -@file{/gnu-stuff/src/configure}, as follows. (Assume for the sake of argument -that our machine is a sun4.) - -@cindex Example session +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 -@group -eg$ cd /gnu-stuff/src -eg$ ./configure sun4 -Created "Makefile" in /gnu-stuff/src -eg$ -@end group +#include "config.h" @end smallexample -We just configured the code in @file{/gnu-stuff/src} to run on a Sun -SPARCstation using SunOS 4.x by creating a @file{Makefile} in -@file{/gnu-stuff/src}. By default, we also specified that when this code is -built, the object code should reside in the same directory, -@file{/gnu-stuff/src}. - -However, if we wanted to build this code for more than one host, we would be in -trouble, because the new configuration would write over the old one, destroying -it in the process. What we can do is to make a new @dfn{build directory} and -configure from there. Running @code{configure} from the new directory will -place a correct @file{Makefile} and a @file{config.status} in this new file. -That is all @code{configure} does; we must run @code{make} to generate any -object code. - -The new @file{Makefile} in @file{/gnu-stuff/sun4-obj}, created from the -template file @file{/gnu-stuff/src/Makefile.in}, contains all the information -needed to build the program. - -@cindex Example session +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 -@group -eg$ mkdir /gnu-stuff/sun4-obj -eg$ cd /gnu-stuff/sun4-obj -eg$ ../src/configure --srcdir=../src sun4 -Created "Makefile" in /gnu-stuff/sun4-obj -eg$ ls -Makefile config.status -eg$ make all info install install-info clean -@var{compilation messages@dots{}} -eg$ mkdir /gnu-stuff/solaris2 -eg$ cd /gnu-stuff/solaris2 -eg$ ../src/configure --srcdir=../src sol2 -Created "Makefile" in /gnu-stuff/solaris2 -eg$ ls -Makefile config.status -eg$ make all info install install-info clean -@var{compilation messages@dots{}} -@end group +aclocal +autoconf +autoheader +automake @end smallexample -We can repeat this for other configurations of the same software simply -by making a new build directory and reconfiguring from inside it. If -you do not specify the @var{hosttype} argument, @code{configure} -will attempt to figure out what kind of machine and operating system you -happen to be using. @xref{config.guess, , Determining system -information}. Of course, this may not always be the configuration you -wish to build. - -@emph{Caution:} If you build more than one configuration for a single program, -remember that you must also specify a different @samp{--prefix} for each -configuration at configure-time. Otherwise, both configurations will be -installed in the same default location (@file{/usr/local}); the configuration -to be installed last would overwrite previously installed configurations. - -@c --------------------------------------------------------------------- -@node Makefile generation -@subsection @code{Makefile} generation -@cindex @code{Makefile} generation - -Cygnus @code{configure} creates a file called @file{Makefile} in the build -directory which can be used with @code{make} to automatically build a given -program or package. @code{configure} also builds a @file{Makefile} for each -relevant subdirectory for a given program or package (irrelevant subdirectories -would be those which contain no code which needs configuring, and which -therefore have no @code{configure} input file @file{configure.in} and no -@file{Makefile} template @file{Makefile.in}). @xref{Running, @code{make} -Invocation, How to Run @code{make}, make, GNU Make}, for details on using -@code{make} to compile your source code. - -Each @file{Makefile} contains variables which have been configured for a -specific build. These build variables are determined when @code{configure} is -run. All build variables have defaults. By default, @code{configure} -generates a @file{Makefile} which specifies: - -@cindex Default configuration -@itemize @bullet -@item a @dfn{native} build, which is to occur +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. -@item in the current directory, and which will be installed +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. -@item in the default installation directory (@file{/usr/local}) when the code -is compiled with @code{make}. +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 -@noindent -Variables are changeable through command-line options to @code{configure} -(@pxref{Invoking configure, , Invoking @code{configure}}). - -If you are porting a new program and intend to use @code{configure}, see -@ref{Porting, , Porting with @code{configure}}, as well as @ref{Makefiles, , -Writing Makefiles, make, GNU Make}, and @ref{Makefiles, , Makefile Conventions, -standards, GNU Coding Standards}. - -@c --------------------------------------------------------------------- -@node config.guess -@subsection Determining system information -@cindex @code{config.guess} - -The shell script @code{config.guess} is called when you do not specify a -@var{hosttype} on the command line to @code{configure}. @code{config.guess} -acquires available system information from your local machine through the shell -command @code{uname}. It compares this information to a database and attempts -to determine a usable three-part system identifier (known as a @dfn{triple}) to -use as your @var{hosttype}. @xref{What configure really does, , What -@code{configure} really does}, to see how this information is used. - -@emph{Note:} If you do not specify a @var{hosttype} on the command line, -@code{configure} will attempt to configure your software to run on the machine -you happen to be using. This may not be the configuration you desire. - -@c --------------------------------------------------------------------- -@node config.status -@subsection @code{config.status} -@cindex @code{config.status} - -The final step in configuring a directory is to create an executable shell -script, @file{config.status}. The main purpose of this file is to allow the -@file{Makefile} for the current directory to rebuild itself, if necessary. It -is usually run from within the @file{Makefile}. @xref{Makefile extensions, , -Extensions to the @sc{gnu} coding standards}. - -@file{config.status} also contains a record of the @code{configure} session -which created it. - -@c --------------------------------------------------------------------- -@node configure.in -@section The @code{configure.in} input file -@cindex @code{configure.in} - -A @file{configure.in} file for Cygnus @code{configure} consists of a -@dfn{per-invocation} section, followed by a @dfn{per-host} section, followed by -a @dfn{per-target} section, optionally followed by a @dfn{post-target} section. -Each section is a shell script fragment, which is executed by the -@code{configure} shell script at an appropriate time. Values are passed among -@code{configure} and the shell fragments through a set of shell variables. -When each section is being interpreted by the shell, the shell's current -directory is the build directory, and any files created by the section (or -referred to by the section) will be relative to the build directory. To -reference files in other places (such as the source directory), prepend a shell -variable such as @samp{$(srcdir)/} to the desired file name. - -@cindex @i{per-invocation} section -The beginning of the @file{configure.in} file begins the @dfn{per-invocation} -section. - -@cindex @i{per-host} section -A line beginning with @samp{# per-host:} begins the @dfn{per-host} section. - -@cindex @i{per-target} section -A line beginning with @samp{# per-target:} begins the @dfn{per-target} section. - -@cindex @i{post-target} section -If it exists, the @dfn{post-target} section begins with @samp{# post-target:}. +@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 -* configure variables:: Variables available to configure.in -* Minimal:: A minimal configure.in -* Declarations:: For each invocation -* per-host:: Host-specific instructions -* per-target:: Target-specific instructions -* post-target:: Instructions to be executed after target info -* Example:: An example configure.in +* Developer Files:: Developer Files. +* Build Files:: Build Files. +* Support Files:: Support Files. @end menu -@c --------------------------------------------------------------------- -@node configure variables -@subsection Variables available to @code{configure.in} -@cindex @file{configure.in} interface -@cindex configure variables - -The following variables pass information between the standard parts of -@code{configure} and the shell-script fragments in @file{configure.in}: - -@table @code -@item srctrigger -@cindex @code{srctrigger} -@vindex srctrigger -Contains the name of a source file that is expected to live in the source -directory. You must usually set this in the @dfn{per-invocation} section of -@file{configure.in}. @code{configure} tests to see that this file exists. If -the file does not exist, @code{configure} prints an error message. This is -used as a sanity check that @file{configure.in} matches the source directory. - -@item srcname -@cindex @code{srcname} -@vindex srcname -Contains the name of the source collection contained in the source directory. -You must usually set this in the @dfn{per-invocation} section of -@file{configure.in}. If the file named in @samp{srctrigger} does not exist, -@code{configure} uses the value of @samp{srcname} when it prints the error -message. - -@item configdirs -@cindex @code{configdirs} -@vindex configdirs -Contains the names of any subdirectories in which @code{configure} should -recurse. You must usually set this in the @dfn{per-invocation} section of -@file{configure.in}. -If @file{Makefile.in} contains a line starting with @samp{SUBDIRS =}, -then it will be replaced with an assignment to @samp{SUBDIRS} using -the value of @samp{configdirs} (if @samp{subdirs} is empty). This can -be used to determine which directories to configure and build depending -on the host and target configurations. -@c Most other matching makefile/config vars use the same name. Why not -@c this? (FIXME). -@c Can we get rid of SUBDIRS-substitution? It doesn't work well with subdirs. -Use @samp{configdirs} (instead of the @samp{subdirs} variable -described below) if you want to be able to partition the -subdirectories, or use independent @file{Makefile} fragments. -Each subdirectory can be independent, and independently reconfigured. - -@item subdirs -@cindex @code{subdirs} -@vindex subdirs -Contains the names of any subdirectories where @code{configure} should create a -@file{Makefile} (in addition to the current directory), @emph{without} -recursively running @code{configure}. Use @samp{subdirs} (instead of the -@samp{configdirs} variable described above) if you want to configure all of the -directories as a unit. Since there is a single invocation of @code{configure} -that configures many directories, all the directories can use the same -@file{Makefile} fragments, and the same @code{configure.in}. +@node Developer Files +@section Developer Files -@item host -@cindex @code{host} -@cindex Canonical ``triple'' -@vindex host -Contains the full configuration name for the host (generated by the script -@file{config.sub} from the name that you entered). This is a three-part -name (commonly referred to as a @dfn{triple}) of the form -@var{cpu}-@var{vendor}-@var{os}. - -There are separate variables @samp{host_cpu}, @samp{host_vendor}, and -@samp{host_os} that you can use to test each of the three parts; this variable -is useful, however, for error messages, and for testing combinations of the -three components. +This section describes the files written or generated by the developer +of a package. -@item host_cpu -@vindex host_cpu -Contains the first element of the canonical triple representing the host -as returned by @file{config.sub}. This is occasionally used to -distinguish between minor variations of a particular vendor's operating -system and sometimes to determine variations in binary format between -the host and the target. - -@item host_vendor -@vindex host_vendor -Contains the second element of the canonical triple representing the host as -returned by @file{config.sub}. This is usually used to distinguish among the -numerous variations of @emph{common} operating systems. -@c "@emph{common} OS" doesn't convey much to me. Is this meant to cover -@c cases like Unix, widespread but with many variations? - -@item host_os -@vindex host_os -Contains the the third element of the canonical triple representing the -host as returned by @file{config.sub}. +@menu +* Developer Files Picture:: Developer Files Picture. +* Written Developer Files:: Written Developer Files. +* Generated Developer Files:: Generated Developer Files. +@end menu -@item target -@cindex @code{target} -@cindex Canonical ``triple'' -@vindex target -Contains the full configuration name (generated by the script @file{config.sub} -from the name that you entered) for the target. Like the host, this is a -three-part name of the form @var{cpu}-@var{vendor}-@var{os}. - -There are separate variables @samp{target_cpu}, @samp{target_vendor}, and -@samp{target_os} that you can use to test each of the three parts; this -variable is useful, however, for error messages, and for testing combinations -of the three components. +@node Developer Files Picture +@subsection Developer Files Picture -@item target_cpu -@vindex target_cpu -Contains the first element of the canonical triple representing the target as -returned by @file{config.sub}. This variable is used heavily by programs which -are involved in building other programs, like the compiler, assembler, linker, -etc. Most programs will not need the @samp{target} variables at all, but this -one could conceivably be used to build a program, for instance, that operated -on binary data files whose byte order or alignment differ from the system where -the program is running. - -@item target_vendor -@vindex target_vendor -Contains the second element of the canonical triple representing the target as -returned by @file{config.sub}. This is usually used to distinguish among the -numerous variations of @emph{common} operating systems or object file -formats. It is sometimes used to switch between different flavors of user -interfaces. -@c above query re "@emph{common} OS" applies here too - -@item target_os -@vindex target_os -Contains the the third element of the canonical triple representing the -target as returned by @file{config.sub}. This variable is used by -development tools to distinguish between subtle variations in object -file formats that some vendors use across operating system releases. It -might also be use to decide which libraries to build or what user -interface the tool should provide. - -@item floating_point -@cindex @code{floating_point} -@cindex @code{nfp} option -@vindex floating_point -Set to @samp{no} if you invoked @code{configure} with the @samp{--nfp} -command-line option, otherwise it is empty. This is a request to target -machines with @dfn{no floating point} unit, even if the targets ordinarily have -floating point units available. - -@item gas -@cindex @code{with-gnu-as} option -@vindex gas -Set to @samp{true} if you invoked @code{configure} with the -@w{@samp{--with-gnu-as}} command line option, otherwise it is empty. This is a -request to assume that the specified @var{hosttype} machine has @sc{gnu} @code{as} -available even if it ordinarily does not. - -@item srcdir -@cindex @code{srcdir} -@vindex srcdir -Set to the name of the directory containing the source for this program. -This will be different from @file{.} if you have specified the -@samp{--srcdir=@var{dir}} option. @samp{srcdir} can indicate either an -absolute path or a path relative to the build directory. - -@item package_makefile_frag -@vindex package_makefile_frag -If set in @file{configure.in}, this variable should be the name a file relative -to @samp{srcdir} to be included in the resulting @file{Makefile}. If the named -file does not exist, @code{configure} will print a warning message. This -variable is not set by @code{configure}. - -@item host_makefile_frag -@vindex host_makefile_frag -If set in @file{configure.in}, this variable should be the name a file relative -to @samp{srcdir} to be included in the resulting @file{Makefile}. If the named -file does not exist, @code{configure} will print a warning message. This -variable is not set by @code{configure}. - -@item target_makefile_frag -@vindex target_makefile_frag -If set in @file{configure.in}, this variable should be the name of a file, -relative to @samp{srcdir}, to be included in the resulting @file{Makefile}. If -the named file does not exist, @code{configure} will print a warning message. -This variable is not set by @code{configure}. - -@item site_makefile_frag -@vindex site_makefile_frag -Set to a file name representing to the default @file{Makefile} fragment for -this host. It may be set in @file{configure.in} to override this default. -Normally @samp{site_makefile_frag} is empty, but will have a value if you -specify @samp{--site=@var{site}} on the command line. -@ignore -- this doesn't fit -It is probably not a good idea to override this variable from -@file{configure.in}, since that may defeat the @code{configure} user's -intentions. -@end ignore +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 -@vindex Makefile -Set to the name of the generated @file{Makefile}. Normally this value is -precisely @file{Makefile}, but some programs may want something else. - -@item removing -@cindex @code{rm} option -@vindex removing -Normally empty but will be set to some non-null value if you specified -@samp{--rm} on the command line. That is, if @samp{removing} is not empty, -then @code{configure} is @emph{removing} a configuration rather than creating -one. - -@item files -@cindex Symbolic links -@vindex files -If this variable is not empty following the @dfn{per-target} section, -then each word in its value will be the target of a symbolic link named -in the corresponding word from the @samp{links} variable. - -@item links -@cindex Symbolic links -@vindex links -If the @samp{files} variable is not empty following the @dfn{per-target} -section, then @code{configure} creates symbolic links with the first word of -@samp{links} pointing to the first word of @samp{files}, the second word of -@samp{links} pointing to the second word of @samp{files}, and so on. +@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 -@c --------------------------------------------------------------------- -@node Minimal -@subsection A minimal @code{configure.in} -@cindex Minimal @file{configure.in} example +@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 -A minimal @file{configure.in} consists of four lines. +@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. -@example -srctrigger=foo.c -srcname="source for the foo program" -# per-host: -# per-target: -@end example +@menu +* Configuration Name Definition:: Configuration Name Definition. +* Using Configuration Names:: Using Configuration Names. +@end menu -The @samp{# per-host:} and @samp{# per-target:} lines divide the file into the -three required sections. The @samp{srctrigger} line names a file. -@code{configure} checks to see that this file exists in the source directory -before configuring. If the @samp{srctrigger} file does not exist, -@code{configure} uses the value of @samp{srcname} to print an error message -about not finding the source. - -This particular example uses no links, and only the default host, -target, and site-specific @file{Makefile} fragments if they exist. - -@c --------------------------------------------------------------------- -@node Declarations -@subsection For each invocation -@cindex For each invocation -@cindex Declarations section -@cindex @i{per-invocation} section - -@code{configure} invokes the entire shell script fragment from the start of -@file{configure.in} up to a line beginning with @w{@samp{# per-host:}} -immediately after parsing command line arguments. The variables -@samp{srctrigger} and @samp{srcname} @emph{must} be set here. - -You might also want to set the variables @samp{configdirs} and -@samp{package_makefile_frag} here. - -@c --------------------------------------------------------------------- -@node per-host -@subsection Host-specific instructions -@cindex Host-specific instructions -@cindex @i{host} shell-script fragment -@cindex @i{per-host} section - -The @dfn{per-host} section of @file{configure.in} starts with the line that -begins with @w{@samp{# per-host:}} and ends before a line beginning with -@w{@samp{# per-target:}}. @code{configure} invokes the commands in the -@dfn{per-host} section when determining host-specific information. - -This section usually contains a big @code{case} statement using the variable -@samp{host} to determine appropriate values for @samp{host_makefile_frag} and -@samp{files}, although @samp{files} is not usually set here. Usually, it is -set at the end of the @dfn{per-target} section after determining the names of -the target specific configuration files. - -@c --------------------------------------------------------------------- -@node per-target -@subsection Target-specific instructions -@cindex Target-specific instructions -@cindex target shell-script fragment -@cindex @i{per-target} section - -The @dfn{per-target} section of @file{configure.in} starts with the line that -begins with @w{@samp{# per-target:}} and ends before the line that begins with -@w{@samp{# post-target:}}, if there is such a line. Otherwise the -@dfn{per-target} section extends to the end of the file. @code{configure} -invokes the commands in the @dfn{per-target} section when determining -target-specific information, and before building any files, directories, or -links. - -This section usually contains a big @code{case} statement using the variable -@samp{target} to determine appropriate values for @samp{target_makefile_frag} -and @samp{files}. The last lines in the @dfn{per-target} section normally set -the variables @samp{files} and @samp{links}. - -@c --------------------------------------------------------------------- -@node post-target -@subsection Instructions to be executed after target info -@cindex Post-target shell-script fragment -@cindex @i{post-target} section - -The @dfn{post-target} section is optional. If it exists, the -@samp{post-target} section starts with a line beginning with @w{@samp{# -Post-target:}} and extends to the end of the file. If it exists, -@code{configure} invokes this section once for each target after -building all files, directories, or links. - -This section is seldom needed, but you can use it to edit the @file{Makefile} -generated by @code{configure}. - -@c --------------------------------------------------------------------- -@node Example -@subsection An example @code{configure.in} -@cindex Example @file{configure.in} -@cindex Sample @file{configure.in} -@c @cindex @code{bison} @file{configure.in} -@c this won't be the bison configure.in for long.. need better example - -Here is a small example of a @file{configure.in} file. - -@cartouche -@example -@group -# This file is a collection of shell script fragments -# used to tailor a template configure script as -# appropriate for this directory. For more information, -# see configure.texi. +@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 -configdirs= -srctrigger=warshall.c -srcname="bison" +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). -# per-host: +@smallexample case "$@{host@}" in -m88k-motorola-*) - host_makefile_frag=config/mh-delta88 - ;; +i[3456]86-*-linux-gnu*) do something ;; +sparc*-sun-solaris2.[56789]*) do something ;; +sparc*-sun-solaris*) do something ;; +mips*-*-elf*) do something ;; esac +@end smallexample -# per-target: -files="bison_in.hairy" -links="bison.hairy" +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}. -# post-target: -@end group -@end example -@end cartouche +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[3456]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*}. -@c --------------------------------------------------------------------- -@node Install locations -@section Install locations -@cindex Where to install -@cindex Install locations +@node Cross Compilation Tools +@chapter Cross Compilation Tools +@cindex cross tools -Using the default configuration, @samp{make install} creates a single tree of -files, some of which are programs. The location of this tree is determined by -the value of the variable @samp{prefix}. The default value of @samp{prefix} is -@samp{/usr/local}. This is often correct for native tools installed on only -one host. +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 -* prefix:: Changing the default install directory -* exec_prefix:: How to separate host independent files - from host dependent files when - installing for multiple hosts -* Install details:: Full descriptions of all installation subdirectories +* 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 -@c --------------------------------------------------------------------- -@node prefix -@subsection Changing the default install directory -@cindex Changing the install directory -@cindex @code{prefix} option -@vindex prefix - -In the default configuration, all files are installed in subdirectories -of @file{/usr/local}. The location is determined by the value of -the @code{configure} variable @samp{prefix}; in turn, this determines the -value of the @file{Makefile} variable of the same name (@samp{prefix}). - -You can also set the value of the @file{Makefile} variable @samp{prefix} -explicitly each time you invoke @code{make} if you are so inclined. However, -because many programs have this location compiled in, you must specify the -@samp{prefix} value consistently on each invocation of @code{make}, or you will -end up with a broken installation. - -To make this easier, the value of the @code{configure} variable -@samp{prefix} can be set on the command line to @code{configure} -using the option @samp{--prefix=}. - -@c --------------------------------------------------------------------- -@node exec_prefix -@subsection Installing for multiple hosts -@cindex Configuring for multiple hosts -@cindex Sharing host-independent files -@cindex Installing host-independent files -@cindex The @code{exec_prefix} directory -@vindex exec_prefix - -By default, host dependent files are installed in subdirectories of -@file{$(exec_prefix)}. The location is determined by the value of the -@code{configure} variable @samp{exec_prefix}, which determines the value of the -@file{Makefile} variable @samp{exec_prefix}. This makes it easier to install -for a single host, and simplifies changing the default location for the install -tree. The default doesn't allow for multiple hosts to effectively share -host independent files, however. - -To configure so that multiple hosts can share common files, use something like: - -@cindex Example session -@smallexample -configure @var{host1} -prefix=/usr/gnu -exec_prefix=/usr/gnu/H-host1 -make all info install install-info clean +@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 -configure @var{host2} -prefix=/usr/gnu -exec_prefix=/usr/gnu/H-host2 -make all info install install-info -@end smallexample +The shell variables may be used by putting shell code in +@file{configure.in}. For an example, see @ref{Using Configuration +Names}. -The first line configures the source for @var{host1} to place host-specific -programs in subdirectories of @file{/usr/gnu/H-@var{host1}}. - -The second line builds and installs all programs for @var{host1}, -including both host-independent and host-specific files, as well as removing -the host-specific object files from of the build directory. - -The third line reconfigures the source for @var{host2} to place host -specific programs in subdirectories of @file{/usr/gnu/H-@var{host2}}. - -The fourth line builds and installs all programs for @var{host2}. Host -specific files are installed in new directories, but the host -independent files are installed @emph{on top of} the host -independent files installed for @var{host1}. This results in a single -copy of the host independent files, suitable for use by both hosts. - -@xref{Makefile extensions, , Extensions to the @sc{gnu} coding standards}, for -more information. - -@c --------------------------------------------------------------------- -@node Install details -@subsection Full descriptions of all installation subdirectories -@cindex Install details -@cindex Installation subdirectories -@cindex Subdirectories - -During any install, a number of standard directories are created. Their names -are determined by @file{Makefile} variables. Some of the defaults for -@file{Makefile} variables can be changed at configuration time using command -line options to @code{configure}. For more information on the standard -directories or the @file{Makefile} variables, please refer to @ref{Makefiles, , -Makefile Conventions, standards, GNU Coding Standards}. See also @ref{Makefile -extensions, , Extensions to the @sc{gnu} coding standards}. - -Note that @code{configure} does not create the directory indicated by the -variable @samp{srcdir} at any time. @code{$(srcdir)} is not an installation -directory. +@node Specifying the Target +@section Specifying the Target -You can override all @file{Makefile} variables on the command line to -@code{make}. (@xref{Overriding, , Overriding Variables, make, GNU Make}.) If -you do so, you will need to specify the value precisely the same way for each -invocation of @code{make}, or you risk ending up with a broken installation. -This is because many programs have the locations of other programs or files -compiled into them. If you find yourself overriding any of the variables -frequently, you should consider site dependent @file{Makefile} fragments. See -also @ref{Sites, , Adding site info}. - -During @samp{make install}, a number of standard directories are created and -populated. The following @file{Makefile} variables define them. Those whose -defaults are set by corresponding @code{configure} variables are marked -``@code{Makefile} and @code{configure}''. - -@table @code -@item prefix (@code{Makefile} and @code{configure}) -@cindex @code{prefix} -@vindex prefix -The root of the installation tree. You can set its @file{Makefile} default -with the @samp{--prefix=} command line option to @code{configure} -(@pxref{Invoking configure, , Invoking @code{configure}}). The default value -for @samp{prefix} is @samp{/usr/local}. - -@item bindir -@cindex @code{bindir} -@vindex bindir -A directory for binary programs that users can run. The default value for -@samp{bindir} depends on @samp{prefix}; @samp{bindir} is normally changed only -indirectly through @samp{prefix}. The default value for @samp{bindir} is -@samp{$(prefix)/bin}. - -@item exec_prefix (@code{Makefile} and @code{configure}) -@cindex @code{exec_prefix} -@vindex exec_prefix -A directory for host dependent files. You can specify the @file{Makefile} -default value by using the @samp{--exec_prefix=} option to @code{configure}. -(@xref{Invoking configure, , Invoking @code{configure}}.) The default value -for @samp{exec_prefix} is @samp{$(prefix)}. - -@item libdir -@cindex @code{libdir} -@vindex libdir -A directory for libraries and support programs. The default value for -@samp{libdir} depends on @samp{prefix}; @samp{libdir} is normally changed only -indirectly through @samp{prefix}. The default value for @samp{libdir} is -@samp{$(prefix)/lib}. - -@item mandir -@cindex @code{mandir} -@vindex mandir -A directory for @code{man} format documentation (``man pages''). The default -value for @samp{mandir} depends on @samp{prefix}; @samp{mandir} is normally -changed only indirectly through @samp{prefix}. The default value for -@samp{mandir} is @samp{$(prefix)/man}. - -@item man@var{N}dir -@cindex @code{man@var{N}dir} -@vindex man@var{N}dir -These are eight variables named @samp{man1dir}, @samp{man2dir}, etc. They name -the specific directories for each man page section. For example, -@samp{man1dir} by default holds the filename @file{$(mandir)/man1}; this -directory contains @file{emacs.1} (the man page for @sc{gnu} Emacs). -Similarly, @samp{man5dir} contains the value @file{$(mandir)/man5}, indicating -the directory which holds @file{rcsfile.5} (the man page describing the -@code{rcs} data file format). The default value for any of the -@samp{man@var{N}dir} variables depends indirectly on @samp{prefix}, and is -normally changed only through @samp{prefix}. The default value for -@samp{man@var{N}dir} is @samp{$(mandir)/man@var{N}}. - -@item man@var{N}ext -@cindex @code{man@var{N}ext} -@vindex man@var{N}ext -@emph{Not supported by Cygnus @code{configure}}. The @cite{@sc{gnu} Coding -Standards} do not call for @samp{man1ext}, @samp{man2ext}, so the intended use -for @code{manext} is apparently not parallel to @samp{mandir}. Its use is not -clear. (See also @ref{Makefile extensions, , Extensions to the @sc{gnu} coding -standards}.) - -@item infodir -@cindex @code{infodir} -@vindex infodir -A directory for @code{info} format documentation. The default value for -@samp{infodir} depends indirectly on @samp{prefix}; @samp{infodir} is -normally changed only through @samp{prefix}. The default value for -@samp{infodir} is @samp{$(prefix)/info}. - -@item docdir -@cindex @code{docdir} -@vindex docdir -A directory for any documentation that is in a format other than those used by -@code{info} or @code{man}. The default value for @samp{docdir} depends -indirectly on @samp{prefix}; @samp{docdir} is normally changed only through -@samp{prefix}. The default value for @samp{docdir} is @samp{$(datadir)/doc}. -@emph{This variable is an extension to the @sc{gnu} coding standards}. (See -also @ref{Makefile extensions, , Extensions to the @sc{gnu} coding standards}.) - -@item includedir -@cindex @code{includedir} -@vindex includedir -A directory for the header files accompanying the libraries installed in -@samp{libdir}. The default value for @samp{includedir} depends on -@samp{prefix}; @samp{includedir} is normally changed only indirectly -through @samp{prefix}. The default value for @samp{includedir} is -@samp{$(prefix)/include}. -@end table +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. -@c --------------------------------------------------------------------- -@node Host -@section Host -@cindex Host - -The arguments to @code{configure} are @dfn{hosttypes}. By -@dfn{hosttype} we mean the @dfn{environment} in which the source will be -compiled. This need not necessarily be the same as the physical machine -involved, although it usually is. - -For example, if some obscure machine had the @sc{gnu} @code{POSIX} emulation -libraries available, it would be possible to configure most @sc{gnu} source for -a @code{POSIX} system and build it on the obscure host. - -For more on this topic, see @ref{Host Environments, On Configuring Development -Tools, Host Environments, cfg-paper, On Configuring Development Tools}. - -@c --------------------------------------------------------------------- -@node Target -@section Target -@cindex Target - -For building native development tools, or most of the other @sc{gnu} -tools, you need not worry about the target. The @dfn{target} of a -configuration defaults to the same as the @dfn{host}. - -For building cross development tools, please see @ref{Building Development -Environments, On Configuring Development Tools, Building Development -Environments, cfg-paper, On Configuring Development Tools}. - -@c --------------------------------------------------------------------- -@node Makefile fragments -@section Adding information about local conventions -@cindex @code{Makefile} fragments -@cindex Local conventions -@cindex Adding local info -@cindex Adding site info - -If you find that a tool does not get configured to your liking, or if -@code{configure}'s conventions differ from your local conventions, you should -probably consider @dfn{site-specific @file{Makefile} fragments}. See also -@ref{Sites, , Adding site info}. - -These are probably not the right choice for options that can be set from -the @code{configure} command line or for differences that are host or -target dependent. - -Cygnus @code{configure} uses three types of @file{Makefile} fragments. In a -generated @file{Makefile} they appear in the order: @dfn{target fragment}, -@dfn{host fragment}, and @dfn{site fragment}. This allows host fragments to -override target fragments, and site fragments to override both. - -Host-specific @file{Makefile} fragments conventionally reside in the -@file{./config/} subdirectory with names of the form @file{mh-@var{hosttype}}. -They are used for hosts that require odd options to the standard compiler and -for compile time options based on the host configuration. - -Target-specific @file{Makefile} fragments conventionally reside in the -@file{./config/} subdirectory with names of the form @file{mt-@var{target}}. -They are used for target dependent compile time options. - -Site specific @file{Makefile} fragments conventionally reside in the -@file{./config/} subdirectory with names of the form @file{ms-@var{site}}. -They are used to override host- and target-independent compile time options. -Note that you can also override these options on the @code{make} invocation -line. - -@c --------------------------------------------------------------------- -@node Makefile extensions -@section Extensions to the @sc{gnu} coding standards -@cindex @code{Makefile} extensions -@cindex Cygnus extensions -@cindex Coding standards extensions - -The following additions to the @sc{gnu} coding standards are required for -Cygnus @code{configure} to work properly. +@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}. -@itemize @bullet -@item -The @file{Makefile} must contain exactly one line starting with @samp{####}. -This line should follow any default macro definitions but precede any rules. -Host, target, and site-specific @file{Makefile} fragments will be inserted -immediately after this line. If the line is missing, the fragments will not be -inserted. +For example, to build tools which generate code for a MIPS ELF embedded +system, you would use @samp{--target mips-elf}. -@item -Cygnus adds the following targets to each @file{Makefile}. Their existence is -not required for Cygnus @code{configure}, but they are documented here for -completeness. +@node Using the Target Type +@section Using the Target Type -@table @code -@kindex info -@item info -Build all info files from texinfo source. +@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}. -@kindex install-info -@item install-info -Install all info files. +@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}). -@kindex clean-info -@item clean-info -Remove all info files and any intermediate files that can be generated -from texinfo source. +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}. -@kindex Makefile -@item Makefile -Calls @code{./config.status} to rebuild the @file{Makefile} in this directory. +@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 -@item -The following @file{Makefile} targets have revised semantics: - -@table @code -@kindex install -@item install -Should @emph{not} depend on the target @samp{all}. If the program is not -already built, @samp{make install} should fail. This allows you to install -programs even when @code{make} would otherwise determine them to be out of -date. This can happen, for example, when the result of a @samp{make all} is -transported via tape to another machine for installation. - -@kindex clean -@item clean -Should remove any file that can be regenerated by the @file{Makefile}, -excepting only the @file{Makefile} itself, and any links created by -@code{configure}. That is, @code{make all clean} should return all directories -to their original condition. If this is not done, then the command sequence - -@cindex Example session -@example -configure @var{host1} ; make all install clean ; -configure @var{host2} ; make all install -@end example +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. -@noindent -will fail because of intermediate files intended for @var{host1}. -@end table +@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 -@item -Cygnus adds the following macros to all @file{Makefile.in} files, but -you are not required to use them to run Cygnus @code{configure}. - -@table @code -@kindex docdir -@item docdir -The directory in which to install any documentation that is not either a -@code{man} page or an @code{info} file. For @code{man} pages, see -@samp{mandir}; for @code{info}, see @samp{infodir}. - -@kindex includedir -@item includedir -The directory in which to install any header files that should be made -available to users. This is distinct from the @code{gcc} include directory, -which is intended for @code{gcc} only. Files in @samp{includedir} may be used -by @code{cc} as well. -@end table +@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 -The following macros have revised semantics. Most of them describe -installation directories; see also @ref{Install details, , Full description of -all installation subdirectories}. - -@table @code -@kindex datadir -@item datadir -is used for host independent data files. - -@kindex mandir -@item mandir -The default path for @samp{mandir} depends on @samp{prefix}. - -@kindex infodir -@item infodir -The default path for @samp{infodir} depends on @samp{prefix}. - -@kindex BISON -@item BISON -is assumed to have a @code{yacc} calling convention. To use @sc{gnu} -@code{bison}, use @samp{BISON=bison -y}. -@end table - +Build the host libraries. @item -Each Cygnus @file{Makefile} also conforms to one additional restriction: - -When libraries are installed, the line containing the call to -@samp{INSTALL_DATA} should always be followed by a line containing a call to -@samp{RANLIB} on the installed library. This is to accommodate systems that -use @code{ranlib}. Systems that do not use @code{ranlib} can set @samp{RANLIB} -to ``@code{echo}'' in a host specific @file{Makefile} fragment. +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 -@c ======================================================================== -@node Porting -@chapter Porting with @code{configure} -@cindex Porting with @code{configure} - -This section explains how to add programs, host and target configuration -names, and site-specific information to Cygnus @code{configure}. +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 -* Programs:: Adding configure to new programs -* Hosts and targets:: Adding hosts and targets -* Sites:: Adding site info +* 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 -@c --------------------------------------------------------------------- -@node Programs -@section Adding @code{configure} to new programs -@cindex Adding @code{configure} to new programs - -If you are writing a new program, you probably shouldn't worry about porting or -configuration issues until it is running reasonably on some host. Then refer -back to this section. - -If your program currently has a @code{configure} script that meets the @sc{gnu} -standards (@pxref{Configuration, , How Configuration Should Work, standards, -GNU Coding Standards}, please do not add Cygnus @code{configure}. It should be -possible to add this program without change to a Cygnus @code{configure} style -source tree. - -@cindex @code{autoconf} -If the program is not target dependent, please consider using @code{autoconf} -instead of Cygnus @code{configure}. @code{autoconf} is available from the Free -Software Foundation; it is a program which generates an executable shell script -called @file{configure} by automatically finding information on the system to -be configured on and embedding this information in the shell script. -@file{configure} scripts generated by @code{autoconf} require no arguments, and -accept the same options as Cygnus @code{configure}. For detailed instructions -on using @code{autoconf}, see @ref{Making configure Scripts, , How to organize -and produce Autoconf scripts, autoconf, Autoconf}. - - -To add Cygnus @code{configure} to an existing program, do the following: - -@table @bullet -@item Make sure the @file{Makefile} conforms to the @sc{gnu} standard -The coding standard for writing a @sc{gnu} @file{Makefile} is described in -@ref{Makefiles, , Makefile Conventions, standards, GNU Coding Standards}. For -technical information on writing a @file{Makefile}, see @ref{Makefiles, , -Writing Makefiles, make, GNU Make}. - -@item Add Cygnus extensions to the @file{Makefile} -These are described in @ref{Makefile extensions, , Extensions to the @sc{gnu} -coding standards}. - -@item Collect package specific definitions in a single file -Many packages are best configured using a common @file{Makefile} fragment which -is included by all of the makefiles in the different directories of the -package. In order to accomplish this, set the variable -@samp{package_makefile_fragment} to the name of the file. It will be inserted -into the final @file{Makefile} before the target-specific fragment. - -@item Move host support from @file{Makefile} to fragments -This usually involves finding sections of the @file{Makefile} that say things -like ``uncomment these lines for host @var{hosttype}'' and moving them to a new -file called @file{./config/mh-@var{hosttype}}. For more information, see @ref{Hosts -and targets, , Adding hosts and targets}. - -@item Choose defaults -If the program has compile-time options that determine the way the program -should behave, choose reasonable defaults and make these @file{Makefile} -variables. Be sure the variables are assigned their default values before the -@samp{####} line so that site-specific @file{Makefile} fragments can override -them (@pxref{Makefile extensions, , Extensions to the @sc{gnu} coding -standards}). - -@item Locate configuration files -If there is configuration information in header files or source files, separate -it in such a way that the files have generic names. Then move the specific -instances of those files into the @file{./config/} subdirectory. - -@item Separate host and target information -Some programs already have this information separated. If yours does not, you -will need to separate these two kinds of configuration information. @dfn{Host -specific} information is the information needed to compile the program. -@dfn{Target specific} information is information on the format of data files -that the program will read or write. This information should live in separate -files in the @file{./config/} subdirectory with names that reflect the -configuration for which they are intended. - -At this point you might skip this step and simply move on. If you do, you -should end up with a program that can be configured only to build @dfn{native} -tools, that is, tools for which the host system is also the target system. -Later, you could attempt to build a cross tool and separate out the -target-specific information by figuring out what went wrong. This is often -simpler than combing through all of the source code. - -@item Write @code{configure.in} -Usually this involves writing shell script fragments to map from canonical -configuration names into the names of the configuration files. These files -will then be linked at configure time from the specific instances of those -files in @file{./config} to files in the build directory with more generic -names. (See also @ref{Build directories, , Build directories}.) The format of -@file{configure.in} is described in @ref{configure.in, , The -@code{configure.in} input file}. - -@item Rename @file{Makefile} to @file{Makefile.in} -@end table +@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. -At this point you should have a program that can be configured using -Cygnus @code{configure}. +@menu +* Standard Cygnus CCross:: Building a Normal Program. +* Cross Cygnus CCross:: Building a Cross Program. +@end menu -@c --------------------------------------------------------------------- -@node Hosts and targets -@section Adding hosts and targets -@cindex Adding hosts and targets -@cindex Hosts and targets +@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). -To add a host or target to a program that already uses Cygnus @code{configure}, -do the following. +@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 -@itemize @bullet +You would then copy the contents of @var{wininstalldir} over to the +Windows machine, and run the resulting programs. -@item -Make sure the new configuration name is represented in @file{config.sub}. If -not, add it. For more details, see the comments in the shell script -@file{config.sub}. +@node Supporting Canadian Cross +@section Supporting Canadian Cross -@item -If you are adding a host configuration, look in @file{configure.in}, in the -@dfn{per-host} section. Make sure that your configuration name is represented -in the mapping from host configuration names to configuration files. If not, -add it. Also see @ref{configure.in, , The @code{configure.in} input file}. +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. -@item -If you are adding a target configuration, look in @file{configure.in}, in the -@dfn{per-target} section. Make sure that your configuration name is -represented in the mapping from target configuration names to configuration -files. If not, add it. Also see @ref{configure.in, , The @code{configure.in} -input file}. +@menu +* CCross in Configure:: Supporting Canadian Cross in Configure Scripts. +* CCross in Make:: Supporting Canadian Cross in Makefiles. +@end menu -@item -Look in @file{configure.in} for the variables @samp{files}, @samp{links}, -@samp{host_makefile_frag}, and @samp{target_makefile_frag}. The values -assigned to these variables are the names of the configuration files, (relative -to @samp{srcdir}) that the program uses. Make sure that copies of the files -exist for your host. If not, create them. See also @ref{configure variables, -, Variables available to @code{configure.in}}. -@end itemize +@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. -This should be enough to @code{configure} for a new host or target -configuration name. Getting the program to compile and run properly represents -the hardest work of any port. +@menu +* Cygnus Configure Basics:: Cygnus Configure Basics. +* Cygnus Configure in C++ Libraries:: Cygnus Configure in C++ Libraries. +@end menu -@c --------------------------------------------------------------------- -@node Sites -@section Adding site info -@cindex Sites -@cindex Adding site info +@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. -If some of the @file{Makefile} defaults are not right for your site, you can -build site-specific @file{Makefile} fragments. To do this, do the following. +@menu +* Multilibs in gcc:: Multilibs in gcc. +* Multilibs in Target Libraries:: Multilibs in Target Libraries. +@end menu -@itemize @bullet +@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 -@item -Choose a name for your site. It must currently be less than eleven characters. +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)..}. -@item -If the program source does not have a @file{./config/} subdirectory, create it. +Similarly, references to the parent of the object directory should use +the variable @samp{MULTIBUILDTOP}. -@item -Create a file called @file{./config/ms-@var{site}} where @var{site} is the name -of your site. In it, set whatever @file{Makefile} variables you need to -override to match your site's conventions. +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}. -@item -Configure the program with: +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. -@cindex Example session -@example -configure @dots{} --site=@var{site} -@end example +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 -@end itemize +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}. -@c --------------------------------------------------------------------- -@node Variables Index -@unnumbered Variable Index +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 -@printindex vr +@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 -@page -@c --------------------------------------------------------------------- -@node Concept Index -@unnumbered Concept Index +@node Index +@unnumbered Index @printindex cp + @contents @bye - -@c Local Variables: -@c fill-column: 79 -@c outline-regexp: "@chap" -@c End: -@c (setq outline-regexp "@chapt\\\|@unnum\\\|@setf\\\|@conte\\\|@sectio\\\|@subsect\\\|@itemize\\\|@defvar{") - |
