On 5/18/21 12:30 AM, Joseph Myers wrote:
On Mon, 17 May 2021, Martin Liška wrote:

-@enumerate
-@item
-If you have chosen a configuration for GCC which requires other GNU
-tools (such as GAS or the GNU linker) instead of the standard system
-tools, install the required tools in the build directory under the names
-@file{as}, @file{ld} or whatever is appropriate.

This bit is obsoleted by --with-build-time-tools (putting tools in the
build directory was needed in some cases before that option was added).

-@item
-Specify the host, build and target machine configurations.  You do this
-when you run the @file{configure} script.

But install.texi doesn't appear to have such documentation of what host,
build and target are and how to specify them.

-Here are the possible CPU types:
-
-@quotation
-@c gmicro, fx80, spur and tahoe omitted since they don't work.
-1750a, a29k, alpha, arm, avr, c@var{n}, clipper, dsp16xx, elxsi, fr30, h8300,
-hppa1.0, hppa1.1, i370, i386, i486, i586, i686, i786, i860, i960, ip2k, m32r,
-m68000, m68k, m88k, mcore, mips, mipsel, mips64, mips64el,
-mn10200, mn10300, ns32k, pdp11, powerpc, powerpcle, romp, rs6000, sh, sparc,
-sparclite, sparc64, v850, vax, we32k.
-@end quotation

The very outdated list of specific names may not be very useful now,
although arguably there *should* be a current list of supported targets
(closer to that in config-list.mk, or at least a list of supported CPU
names and another list of supported OS names) in the installation
documentation.

-Often a particular model of machine has a name.  Many machine names are
-recognized as aliases for CPU/company combinations.  Thus, the machine

All such machine names can probably be considered obsolete; the main case
to document is CPU-SYSTEM (no company mentioned), not machine name aliases
(and mention somewhere that config.sub produces the canonical version of a
name).


All right, the suggested changes make sense to me and I've just tried to address
them in the patch.

Thoughts?
Martin
>From a5af817b5769abf1e58119b9b07968ca0c40bb9d Mon Sep 17 00:00:00 2001
From: Martin Liska <mli...@suse.cz>
Date: Tue, 18 May 2021 11:57:47 +0200
Subject: [PATCH] docs: port old-intall.texi part to install.texi

gcc/ChangeLog:

	* doc/install.texi: Port relevant part from install-old.texi
	and re-generate list of CPUs and systems.
---
 gcc/doc/install.texi | 70 +++++++++++++++++++++++++++++++++++---------
 1 file changed, 56 insertions(+), 14 deletions(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index f0591e06b3e..92c7d5fb279 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -697,23 +697,65 @@ The default value is @uref{https://gcc.gnu.org/,,https://gcc.gnu.org/}.
 
 @end table
 
-@heading Target specification
-@itemize @bullet
-@item
-GCC has code to correctly determine the correct value for @var{target}
-for nearly all native systems.  Therefore, we highly recommend you do
-not provide a configure target when configuring a native compiler.
+@heading Host, Build and Target specification
 
-@item
-@var{target} must be specified as @option{--target=@var{target}}
-when configuring a cross compiler; examples of valid targets would be
-m68k-elf, sh-elf, etc.
+Specify the host, build and target machine configurations.  You do this
+when you run the @file{configure} script.
 
-@item
-Specifying just @var{target} instead of @option{--target=@var{target}}
-implies that the host defaults to @var{target}.
-@end itemize
+The @dfn{build} machine is the system which you are using, the
+@dfn{host} machine is the system where you want to run the resulting
+compiler (normally the build machine), and the @dfn{target} machine is
+the system for which you want the compiler to generate code.
+
+If you are building a compiler to produce code for the machine it runs
+on (a native compiler), you normally do not need to specify any operands
+to @file{configure}; it will try to guess the type of machine you are on
+and use that as the build, host and target machines.  So you don't need
+to specify a configuration when building a native compiler unless
+@file{configure} cannot figure out what your configuration is or guesses
+wrong.
+
+In those cases, specify the build machine's @dfn{configuration name}
+with the @option{--host} option; the host and target will default to be
+the same as the host machine.
+
+Here is an example:
+
+@smallexample
+./configure --host=x86_64-pc-linux-gnu
+@end smallexample
 
+A configuration name may be canonical or it may be more or less
+abbreviated (@file{config.sub} script produces canonical versions).
+
+A canonical configuration name has three parts, separated by dashes.
+It looks like this: @samp{@var{cpu}-@var{company}-@var{system}}.
+
+Here are the possible CPU types:
+
+@quotation
+aarch64, alpha, alpha64, amdgcn, arc, arceb, arm, avr, bfin, bpf, c6x, cr16,
+cris, csky, epiphany, fido, fr30, frv, ft32, h8300, hppa, hppa2.0, hppa64,
+i486, i686, ia64, iq2000, lm32, m32c, m32r, m32rle, m68k, mcore, microblaze,
+mips, mips64, mips64el, mips64octeon, mips64orion, mips64vr, mipsel, mipsisa32,
+mipsisa32r2, mipsisa64, mipsisa64r2, mipsisa64r2el, mipsisa64sb1, mipsisa64sr71k,
+mipstx39, mmix, mn10300, moxie, msp430, nds32be, nds32le, nios2, nvptx, or1k,
+pdp11, powerpc, powerpc64, powerpcle, ppc, pru, riscv32, riscv64, rl78, rx,
+s390, s390x, sh, shle, sparc, sparc64, tilegx, tilegxbe, tilepro, v850, v850e,
+v850e1, vax, visium, x86_64, xstormy16, xtensa
+@end quotation
+
+Here is a list of system types:
+
+@quotation
+aix7.1, aix7.2, amdhsa, androideabi, aout, cygwin, darwin, darwin10, darwin7,
+darwin8, darwin9, eabi, eabialtivec, eabisim, eabisimaltivec, elf, elf32,
+elfbare, elfoabi, freebsd4, freebsd6, gnu, hpux, hpux10.1, hpux11.0, hpux11.3,
+hpux11.9, linux, linux_altivec, lynxos, mingw32, mingw32crt, mmixware, msdosdjgpp,
+musl, netbsd, netbsdelf, netbsdelf9, none, openbsd, qnx, rtems, solaris2.11,
+symbianelf, tpf, uclibc, uclinux, uclinux_eabi, vms, vxworks, vxworksae,
+vxworksmils
+@end quotation
 
 @heading Options specification
 
-- 
2.31.1

Reply via email to