diff options
Diffstat (limited to 'gnu/usr.bin/gcc/INSTALL')
| -rw-r--r-- | gnu/usr.bin/gcc/INSTALL/README | 6 | ||||
| -rw-r--r-- | gnu/usr.bin/gcc/INSTALL/binaries.html | 98 | ||||
| -rw-r--r-- | gnu/usr.bin/gcc/INSTALL/build.html | 247 | ||||
| -rw-r--r-- | gnu/usr.bin/gcc/INSTALL/configure.html | 675 | ||||
| -rw-r--r-- | gnu/usr.bin/gcc/INSTALL/download.html | 67 | ||||
| -rw-r--r-- | gnu/usr.bin/gcc/INSTALL/finalinstall.html | 141 | ||||
| -rw-r--r-- | gnu/usr.bin/gcc/INSTALL/gfdl.html | 446 | ||||
| -rw-r--r-- | gnu/usr.bin/gcc/INSTALL/index.html | 95 | ||||
| -rw-r--r-- | gnu/usr.bin/gcc/INSTALL/old.html | 618 | ||||
| -rw-r--r-- | gnu/usr.bin/gcc/INSTALL/specific.html | 1665 | ||||
| -rw-r--r-- | gnu/usr.bin/gcc/INSTALL/test.html | 162 |
11 files changed, 4220 insertions, 0 deletions
diff --git a/gnu/usr.bin/gcc/INSTALL/README b/gnu/usr.bin/gcc/INSTALL/README new file mode 100644 index 00000000000..27bd1738bca --- /dev/null +++ b/gnu/usr.bin/gcc/INSTALL/README @@ -0,0 +1,6 @@ +This directory has been obsoleted for GCC snapshots and CVS access. + +For releases the installation documentation is generated from +gcc/doc/install.texi and copied into this directory. + +To read this documentation, please point your HTML browser to "index.html". diff --git a/gnu/usr.bin/gcc/INSTALL/binaries.html b/gnu/usr.bin/gcc/INSTALL/binaries.html new file mode 100644 index 00000000000..71da0a61c5c --- /dev/null +++ b/gnu/usr.bin/gcc/INSTALL/binaries.html @@ -0,0 +1,98 @@ +<html lang="en"> +<head> +<title>Installing GCC: Binaries</title> +<meta http-equiv="Content-Type" content="text/html"> +<meta name=description content="Installing GCC: Binaries"> +<meta name=generator content="makeinfo 4.2"> +<link href="http://www.gnu.org/software/texinfo/" rel=generator-home> +<!-- +Copyright © 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, +1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc. +<br><p> +<p>Permission is granted to copy, distribute and/or modify this document +under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no +Invariant Sections, the Front-Cover texts being (a) (see below), and +with the Back-Cover Texts being (b) (see below). A copy of the +license is included in the section entitled "<a href="./gfdl.html">GNU Free Documentation License</a>". + +<p>(a) The FSF's Front-Cover Text is: + +<p>A GNU Manual + +<p>(b) The FSF's Back-Cover Text is: + +<p>You have freedom to copy and modify this GNU Manual, like GNU + software. Copies published by the Free Software Foundation raise + funds for GNU development.--> +</head> +<body> +<h1>Installing GCC: Binaries</h1> +We are often asked about pre-compiled versions of GCC. While we cannot +provide these for all platforms, below you'll find links to binaries for +various platforms where creating them by yourself is not easy due to various +reasons. + +<p>Please note that we did not create these binaries, nor do we +support them. If you have any problems installing them, please +contact their makers. + +<ul> +<li>AIX: +<ul> +<li><a href="http://www.bullfreeware.com">Bull's Freeware and Shareware Archive for AIX</a>; + +<li><a href="http://aixpdslib.seas.ucla.edu">UCLA Software Library for AIX</a>. +</ul> + +<li>DOS--<a href="http://www.delorie.com/djgpp/">DJGPP</a>. + +<li>Renesas H8/300[HS]--<a href="http://h8300-hms.sourceforge.net/">GNU Development Tools for the Renesas H8/300[HS] Series</a>. + +<li>HP-UX: +<ul> +<li><a href="http://hpux.cae.wisc.edu/">HP-UX Porting Center</a>; + +<li><a href="ftp://sunsite.informatik.rwth-aachen.de/pub/packages/gcc_hpux/">Binaries for HP-UX 11.00 at Aachen University of Technology</a>. +</ul> + +<li>Motorola 68HC11/68HC12--<a href="http://www.gnu-m68hc11.org">GNU Development Tools for the Motorola 68HC11/68HC12</a>. + +<li><a href="http://www.sco.com/skunkware/devtools/index.html#gcc">SCO OpenServer/Unixware</a>. + +<li>Sinix/Reliant Unix--<a href="ftp://ftp.fujitsu-siemens.com/pub/pd/gnu/gcc/">Siemens</a>. + +<li>Solaris 2 (SPARC, Intel)--<a href="http://www.sunfreeware.com/">Sunfreeware</a>. + +<li>SGI--<a href="http://freeware.sgi.com/">SGI Freeware</a>. + +<li>Microsoft Windows: +<ul> +<li>The <a href="http://sources.redhat.com/cygwin/">Cygwin</a> project; +<li>The <a href="http://www.mingw.org/">MinGW</a> project. +</ul> + +<li><a href="ftp://ftp.thewrittenword.com/packages/by-name/">The Written Word</a> offers binaries for +AIX 4.3.2. +IRIX 6.5, +Digital UNIX 4.0D and 5.1, +GNU/Linux (i386), +HP-UX 10.20, 11.00, and 11.11, and +Solaris/SPARC 2.5.1, 2.6, 2.7, 8, and 9, +</ul> + +<p>In addition to those specific offerings, you can get a binary +distribution CD-ROM from the +<a href="http://www.fsf.org/order/order.html">Free Software Foundation</a>. +It contains binaries for a number of platforms, and +includes not only GCC, but other stuff as well. The current CD does +not contain the latest version of GCC, but it should allow +bootstrapping the compiler. An updated version of that disk is in the +works. + +<hr /> +<p> +<a href="./index.html">Return to the GCC Installation page</a> + +</body></html> + diff --git a/gnu/usr.bin/gcc/INSTALL/build.html b/gnu/usr.bin/gcc/INSTALL/build.html new file mode 100644 index 00000000000..d1b3a95f407 --- /dev/null +++ b/gnu/usr.bin/gcc/INSTALL/build.html @@ -0,0 +1,247 @@ +<html lang="en"> +<head> +<title>Installing GCC: Building</title> +<meta http-equiv="Content-Type" content="text/html"> +<meta name=description content="Installing GCC: Building"> +<meta name=generator content="makeinfo 4.2"> +<link href="http://www.gnu.org/software/texinfo/" rel=generator-home> +<!-- +Copyright © 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, +1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc. +<br><p> +<p>Permission is granted to copy, distribute and/or modify this document +under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no +Invariant Sections, the Front-Cover texts being (a) (see below), and +with the Back-Cover Texts being (b) (see below). A copy of the +license is included in the section entitled "<a href="./gfdl.html">GNU Free Documentation License</a>". + +<p>(a) The FSF's Front-Cover Text is: + +<p>A GNU Manual + +<p>(b) The FSF's Back-Cover Text is: + +<p>You have freedom to copy and modify this GNU Manual, like GNU + software. Copies published by the Free Software Foundation raise + funds for GNU development.--> +</head> +<body> +<h1>Installing GCC: Building</h1> +Now that GCC is configured, you are ready to build the compiler and +runtime libraries. + +<p>We <strong>highly</strong> recommend that GCC be built using GNU make; +other versions may work, then again they might not. +GNU make is required for compiling GNAT (the Ada compiler) and the Java +runtime library. + +<p>(For example, many broken versions of make will fail if you use the +recommended setup where <var>objdir</var> is different from <var>srcdir</var>. +Other broken versions may recompile parts of the compiler when +installing the compiler.) + +<p>Some commands executed when making the compiler may fail (return a +nonzero status) and be ignored by <code>make</code>. These failures, which +are often due to files that were not found, are expected, and can safely +be ignored. + +<p>It is normal to have compiler warnings when compiling certain files. +Unless you are a GCC developer, you can generally ignore these warnings +unless they cause compilation to fail. + +<p>On certain old systems, defining certain environment variables such as +<code>CC</code> can interfere with the functioning of <code>make</code>. + +<p>If you encounter seemingly strange errors when trying to build the +compiler in a directory other than the source directory, it could be +because you have previously configured the compiler in the source +directory. Make sure you have done all the necessary preparations. + +<p>If you build GCC on a BSD system using a directory stored in an old System +V file system, problems may occur in running <code>fixincludes</code> if the +System V file system doesn't support symbolic links. These problems +result in a failure to fix the declaration of <code>size_t</code> in +<code>sys/types.h</code>. If you find that <code>size_t</code> is a signed type and +that type mismatches occur, this could be the cause. + +<p>The solution is not to use such a directory for building GCC. + +<p>When building from CVS or snapshots, or if you modify parser sources, +you need the Bison parser generator installed. Any version 1.25 or +later should work; older versions may also work. If you do not modify +parser sources, releases contain the Bison-generated files and you do +not need Bison installed to build them. + +<p>When building from CVS or snapshots, or if you modify Texinfo +documentation, you need version 4.2 or later of Texinfo installed if you +want Info documentation to be regenerated. Releases contain Info +documentation pre-built for the unmodified documentation in the release. + +<h3><a name="TOC0"></a>Building a native compiler</h3> + +<p>For a native build issue the command <code>make bootstrap</code>. This +will build the entire GCC system, which includes the following steps: + +<ul> +<li>Build host tools necessary to build the compiler such as texinfo, bison, +gperf. + +<li>Build target tools for use by the compiler such as binutils (bfd, +binutils, gas, gprof, ld, and opcodes) +if they have been individually linked +or moved into the top level GCC source tree before configuring. + +<li>Perform a 3-stage bootstrap of the compiler. + +<li>Perform a comparison test of the stage2 and stage3 compilers. + +<li>Build runtime libraries using the stage3 compiler from the previous step. + +</ul> + +<p>If you are short on disk space you might consider <code>make +bootstrap-lean</code> instead. This is identical to <code>make +bootstrap</code> except that object files from the stage1 and +stage2 of the 3-stage bootstrap of the compiler are deleted as +soon as they are no longer needed. + +<p>If you want to save additional space during the bootstrap and in +the final installation as well, you can build the compiler binaries +without debugging information as in the following example. This will save +roughly 40% of disk space both for the bootstrap and the final installation. +(Libraries will still contain debugging information.) + +<br><pre> make CFLAGS='-O' LIBCFLAGS='-g -O2' \ + LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap +</pre> + +<p>If you wish to use non-default GCC flags when compiling the stage2 and +stage3 compilers, set <code>BOOT_CFLAGS</code> on the command line when doing +<code>make bootstrap</code>. Non-default optimization flags are less well +tested here than the default of <code>-g -O2</code>, but should still work. +In a few cases, you may find that you need to specify special flags such +as <code>-msoft-float</code> here to complete the bootstrap; or, if the +native compiler miscompiles the stage1 compiler, you may need to work +around this, by choosing <code>BOOT_CFLAGS</code> to avoid the parts of the +stage1 compiler that were miscompiled, or by using <code>make +bootstrap4</code> to increase the number of stages of bootstrap. + +<p>If you used the flag <code>--enable-languages=<small>...</small></code> to restrict +the compilers to be built, only those you've actually enabled will be +built. This will of course only build those runtime libraries, for +which the particular compiler has been built. Please note, +that re-defining <code>LANGUAGES</code> when calling <code>make bootstrap</code> +<strong>does not</strong> work anymore! + +<p>If the comparison of stage2 and stage3 fails, this normally indicates +that the stage2 compiler has compiled GCC incorrectly, and is therefore +a potentially serious bug which you should investigate and report. (On +a few systems, meaningful comparison of object files is impossible; they +always appear "different". If you encounter this problem, you will +need to disable comparison in the <code>Makefile</code>.) + +<h3><a name="TOC1"></a>Building a cross compiler</h3> + +<p>We recommend reading the +<a href="http://www.objsw.com/CrossGCC/">crossgcc FAQ</a> +for information about building cross compilers. + +<p>When building a cross compiler, it is not generally possible to do a +3-stage bootstrap of the compiler. This makes for an interesting problem +as parts of GCC can only be built with GCC. + +<p>To build a cross compiler, we first recommend building and installing a +native compiler. You can then use the native GCC compiler to build the +cross compiler. The installed native compiler needs to be GCC version +2.95 or later. + +<p>Assuming you have already installed a native copy of GCC and configured +your cross compiler, issue the command <code>make</code>, which performs the +following steps: + +<ul> +<li>Build host tools necessary to build the compiler such as texinfo, bison, +gperf. + +<li>Build target tools for use by the compiler such as binutils (bfd, +binutils, gas, gprof, ld, and opcodes) +if they have been individually linked or moved into the top level GCC source +tree before configuring. + +<li>Build the compiler (single stage only). + +<li>Build runtime libraries using the compiler from the previous step. +</ul> + +<p>Note that if an error occurs in any step the make process will exit. + +<h3><a name="TOC2"></a>Building in parallel</h3> + +<p>You can use <code>make bootstrap MAKE="make -j 2" -j 2</code>, or just +<code>make -j 2 bootstrap</code> for GNU Make 3.79 and above, instead of +<code>make bootstrap</code> to build GCC in parallel. +You can also specify a bigger number, and in most cases using a value +greater than the number of processors in your machine will result in +fewer and shorter I/O latency hits, thus improving overall throughput; +this is especially true for slow drives and network filesystems. + +<h3><a name="TOC3"></a>Building the Ada compiler</h3> + +<p>In order to build GNAT, the Ada compiler, you need a working GNAT +compiler (GNAT version 3.13 or later, or GCC version 3.1 or later), +since the Ada front end is written in Ada (with some +GNAT-specific extensions), and GNU make. + +<p>However, you do not need a full installation of GNAT, just the GNAT +binary <code>gnat1</code>, a copy of <code>gnatbind</code>, and a compiler driver +which can deal with Ada input (by invoking the <code>gnat1</code> binary). +You can specify this compiler driver by setting the <code>ADAC</code> +environment variable at the configure step. <code>configure</code> can +detect the driver automatically if it has got a common name such as +<code>gcc</code> or <code>gnatgcc</code>. Of course, you still need a working +C compiler (the compiler driver can be different or not). +<code>configure</code> does not test whether the GNAT installation works +and has a sufficiently recent version; if too old a GNAT version is +installed, the build will fail unless <code>--enable-languages</code> is +used to disable building the Ada front end. + +<p>Additional build tools (such as <code>gnatmake</code>) or a working GNAT +run-time library installation are usually <em>not</em> required. However, +if you want to bootstrap the compiler using a minimal version of GNAT, +you have to issue the following commands before invoking <code>make +bootstrap</code> (this assumes that you start with an unmodified and consistent +source distribution): + +<br><pre> cd <var>srcdir</var>/gcc/ada + touch treeprs.ads [es]info.h nmake.ad[bs] +</pre> + +<p>At the moment, the GNAT library and several tools for GNAT are not built +by <code>make bootstrap</code>. You have to invoke +<code>make gnatlib_and_tools</code> in the <code><var>objdir</var>/gcc</code> +subdirectory before proceeding with the next steps. + +<p>For example, you can build a native Ada compiler by issuing the +following commands (assuming <code>make</code> is GNU make): + +<br><pre> cd <var>objdir</var> + <var>srcdir</var>/configure --enable-languages=c,ada + cd <var>srcdir</var>/gcc/ada + touch treeprs.ads [es]info.h nmake.ad[bs] + cd <var>objdir</var> + make bootstrap + cd gcc + make gnatlib_and_tools + cd .. +</pre> + +<p>Currently, when compiling the Ada front end, you cannot use the parallel +build feature described in the previous section. + +<hr /> +<p> +<a href="./index.html">Return to the GCC Installation page</a> + +</body></html> + diff --git a/gnu/usr.bin/gcc/INSTALL/configure.html b/gnu/usr.bin/gcc/INSTALL/configure.html new file mode 100644 index 00000000000..5f425a08af7 --- /dev/null +++ b/gnu/usr.bin/gcc/INSTALL/configure.html @@ -0,0 +1,675 @@ +<html lang="en"> +<head> +<title>Installing GCC: Configuration</title> +<meta http-equiv="Content-Type" content="text/html"> +<meta name=description content="Installing GCC: Configuration"> +<meta name=generator content="makeinfo 4.2"> +<link href="http://www.gnu.org/software/texinfo/" rel=generator-home> +<!-- +Copyright © 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, +1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc. +<br><p> +<p>Permission is granted to copy, distribute and/or modify this document +under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no +Invariant Sections, the Front-Cover texts being (a) (see below), and +with the Back-Cover Texts being (b) (see below). A copy of the +license is included in the section entitled "<a href="./gfdl.html">GNU Free Documentation License</a>". + +<p>(a) The FSF's Front-Cover Text is: + +<p>A GNU Manual + +<p>(b) The FSF's Back-Cover Text is: + +<p>You have freedom to copy and modify this GNU Manual, like GNU + software. Copies published by the Free Software Foundation raise + funds for GNU development.--> +</head> +<body> +<h1>Installing GCC: Configuration</h1> +Like most GNU software, GCC must be configured before it can be built. +This document describes the recommended configuration procedure +for both native and cross targets. + +<p>We use <var>srcdir</var> to refer to the toplevel source directory for +GCC; we use <var>objdir</var> to refer to the toplevel build/object directory. + +<p>If you obtained the sources via CVS, <var>srcdir</var> must refer to the top +<code>gcc</code> directory, the one where the <code>MAINTAINERS</code> can be found, +and not its <code>gcc</code> subdirectory, otherwise the build will fail. + +<p>If either <var>srcdir</var> or <var>objdir</var> is located on an automounted NFS +file system, the shell's built-in <code>pwd</code> command will return +temporary pathnames. Using these can lead to various sorts of build +problems. To avoid this issue, set the <code>PWDCMD</code> environment +variable to an automounter-aware <code>pwd</code> command, e.g., +<code>pawd</code> or <code>amq -w</code>, during the configuration and build +phases. + +<p>First, we <strong>highly</strong> recommend that GCC be built into a +separate directory than the sources which does <strong>not</strong> reside +within the source tree. This is how we generally build GCC; building +where <var>srcdir</var> == <var>objdir</var> should still work, but doesn't +get extensive testing; building where <var>objdir</var> is a subdirectory +of <var>srcdir</var> is unsupported. + +<p>If you have previously built GCC in the same directory for a +different target machine, do <code>make distclean</code> to delete all files +that might be invalid. One of the files this deletes is <code>Makefile</code>; +if <code>make distclean</code> complains that <code>Makefile</code> does not exist +or issues a message like "don't know how to make distclean" it probably +means that the directory is already suitably clean. However, with the +recommended method of building in a separate <var>objdir</var>, you should +simply use a different <var>objdir</var> for each target. + +<p>Second, when configuring a native system, either <code>cc</code> or +<code>gcc</code> must be in your path or you must set <code>CC</code> in +your environment before running configure. Otherwise the configuration +scripts may fail. + +<p>Note that the bootstrap compiler and the resulting GCC must be link +compatible, else the bootstrap will fail with linker errors about +incompatible object file formats. Several multilibed targets are +affected by this requirement, see +<a href="specific.html">host/target specific installation notes</a>. + +<p>To configure GCC: + +<br><pre> % mkdir <var>objdir</var> + % cd <var>objdir</var> + % <var>srcdir</var>/configure [<var>options</var>] [<var>target</var>] +</pre> + +<h3><a name="TOC0"></a>Target specification</h3> + +<ul> +<li>GCC has code to correctly determine the correct value for <var>target</var> +for nearly all native systems. Therefore, we highly recommend you not +provide a configure target when configuring a native compiler. + +<li><var>target</var> must be specified as <code>--target=<var>target</var></code> +when configuring a cross compiler; examples of valid targets would be +i960-rtems, m68k-coff, sh-elf, etc. + +<li>Specifying just <var>target</var> instead of <code>--target=<var>target</var></code> +implies that the host defaults to <var>target</var>. +</ul> + +<h3><a name="TOC1"></a>Options specification</h3> + +<p>Use <var>options</var> to override several configure time options for +GCC. A list of supported <var>options</var> follows; <code>configure +--help</code> may list other options, but those not listed below may not +work and should not normally be used. + +<dl> +<dt><code>--prefix=<var>dirname</var></code> +<dd>Specify the toplevel installation +directory. This is the recommended way to install the tools into a directory +other than the default. The toplevel installation directory defaults to +<code>/usr/local</code>. + +<p>We <strong>highly</strong> recommend against <var>dirname</var> being the same or a +subdirectory of <var>objdir</var> or vice versa. If specifying a directory +beneath a user's home directory tree, some shells will not expand +<var>dirname</var> correctly if it contains the <code>~</code> metacharacter; use +<code>$HOME</code> instead. + +<p>These additional options control where certain parts of the distribution +are installed. Normally you should not need to use these options. +<dl> +<dt><code>--exec-prefix=<var>dirname</var></code> +<dd>Specify the toplevel installation directory for architecture-dependent +files. The default is <code><var>prefix</var></code>. + +<br><dt><code>--bindir=<var>dirname</var></code> +<dd>Specify the installation directory for the executables called by users +(such as <code>gcc</code> and <code>g++</code>). The default is +<code><var>exec-prefix</var>/bin</code>. + +<br><dt><code>--libdir=<var>dirname</var></code> +<dd>Specify the installation directory for object code libraries and +internal parts of GCC. The default is <code><var>exec-prefix</var>/lib</code>. + +<br><dt><code>--with-slibdir=<var>dirname</var></code> +<dd>Specify the installation directory for the shared libgcc library. The +default is <code><var>libdir</var></code>. + +<br><dt><code>--infodir=<var>dirname</var></code> +<dd>Specify the installation directory for documentation in info format. +The default is <code><var>prefix</var>/info</code>. + +<br><dt><code>--datadir=<var>dirname</var></code> +<dd>Specify the installation directory for some architecture-independent +data files referenced by GCC. The default is <code><var>prefix</var>/share</code>. + +<br><dt><code>--mandir=<var>dirname</var></code> +<dd>Specify the installation directory for manual pages. The default is +<code><var>prefix</var>/man</code>. (Note that the manual pages are only extracts from +the full GCC manuals, which are provided in Texinfo format. The manpages +are derived by an automatic conversion process from parts of the full +manual.) + +<br><dt><code>--with-gxx-include-dir=<var>dirname</var></code> +<dd>Specify +the installation directory for G++ header files. The default is +<code><var>prefix</var>/include/g++-v3</code>. + +</dl> + +<br><dt><code>--program-prefix=<var>prefix</var></code> +<dd>GCC supports some transformations of the names of its programs when +installing them. This option prepends <var>prefix</var> to the names of +programs to install in <var>bindir</var> (see above). For example, specifying +<code>--program-prefix=foo-</code> would result in <code>gcc</code> +being installed as <code>/usr/local/bin/foo-gcc</code>. + +<br><dt><code>--program-suffix=<var>suffix</var></code> +<dd>Appends <var>suffix</var> to the names of programs to install in <var>bindir</var> +(see above). For example, specifying <code>--program-suffix=-3.1</code> +would result in <code>gcc</code> being installed as +<code>/usr/local/bin/gcc-3.1</code>. + +<br><dt><code>--program-transform-name=<var>pattern</var></code> +<dd>Applies the <code>sed</code> script <var>pattern</var> to be applied to the names +of programs to install in <var>bindir</var> (see above). <var>pattern</var> has to +consist of one or more basic <code>sed</code> editing commands, separated by +semicolons. For example, if you want the <code>gcc</code> program name to be +transformed to the installed program <code>/usr/local/bin/myowngcc</code> and +the <code>g++</code> program name to be transformed to +<code>/usr/local/bin/gspecial++</code> without changing other program names, +you could use the pattern +<code>--program-transform-name='s/^gcc$/myowngcc/; s/^g++$/gspecial++/'</code> +to achieve this effect. + +<p>All three options can be combined and used together, resulting in more +complex conversion patterns. As a basic rule, <var>prefix</var> (and +<var>suffix</var>) are prepended (appended) before further transformations +can happen with a special transformation script <var>pattern</var>. + +<p>As currently implemented, this option only takes effect for native +builds; cross compiler binaries' names are not transformed even when a +transformation is explicitly asked for by one of these options. + +<p>For native builds, some of the installed programs are also installed +with the target alias in front of their name, as in +<code>i686-pc-linux-gnu-gcc</code>. All of the above transformations happen +before the target alias is prepended to the name - so, specifying +<code>--program-prefix=foo-</code> and <code>program-suffix=-3.1</code>, the +resulting binary would be installed as +<code>/usr/local/bin/i686-pc-linux-gnu-foo-gcc-3.1</code>. + +<p>As a last shortcoming, none of the installed Ada programs are +transformed yet, which will be fixed in some time. + +<br><dt><code>--with-local-prefix=<var>dirname</var></code> +<dd>Specify the +installation directory for local include files. The default is +<code>/usr/local</code>. Specify this option if you want the compiler to +search directory <code><var>dirname</var>/include</code> for locally installed +header files <em>instead</em> of <code>/usr/local/include</code>. + +<p>You should specify <code>--with-local-prefix</code> <strong>only</strong> if your +site has a different convention (not <code>/usr/local</code>) for where to put +site-specific files. + +<p>The default value for <code>--with-local-prefix</code> is <code>/usr/local</code> +regardless of the value of <code>--prefix</code>. Specifying +<code>--prefix</code> has no effect on which directory GCC searches for +local header files. This may seem counterintuitive, but actually it is +logical. + +<p>The purpose of <code>--prefix</code> is to specify where to <em>install +GCC</em>. The local header files in <code>/usr/local/include</code>--if you put +any in that directory--are not part of GCC. They are part of other +programs--perhaps many others. (GCC installs its own header files in +another directory which is based on the <code>--prefix</code> value.) + +<p>Both the local-prefix include directory and the GCC-prefix include +directory are part of GCC's "system include" directories. Although these +two directories are not fixed, they need to be searched in the proper +order for the correct processing of the include_next directive. The +local-prefix include directory is searched before the GCC-prefix +include directory. Another characteristic of system include directories +is that pedantic warnings are turned off for headers in these directories. + +<p>Some autoconf macros add <code>-I <var>directory</var></code> options to the +compiler command line, to ensure that directories containing installed +packages' headers are searched. When <var>directory</var> is one of GCC's +system include directories, GCC will ignore the option so that system +directories continue to be processed in the correct order. This +may result in a search order different from what was specified but the +directory will still be searched. + +<p>GCC automatically searches for ordinary libraries using +<code>GCC_EXEC_PREFIX</code>. Thus, when the same installation prefix is +used for both GCC and packages, GCC will automatically search for +both headers and libraries. This provides a configuration that is +easy to use. GCC behaves in a manner similar to that when it is +installed as a system compiler in <code>/usr</code>. + +<p>Sites that need to install multiple versions of GCC may not want to +use the above simple configuration. It is possible to use the +<code>--program-prefix</code>, <code>--program-suffix</code> and +<code>--program-transform-name</code> options to install multiple versions +into a single directory, but it may be simpler to use different prefixes +and the <code>--with-local-prefix</code> option to specify the location of the +site-specific files for each version. It will then be necessary for +users to specify explicitly the location of local site libraries +(e.g., with <code>LIBRARY_PATH</code>). + +<p>The same value can be used for both <code>--with-local-prefix</code> and +<code>--prefix</code> provided it is not <code>/usr</code>. This can be used +to avoid the default search of <code>/usr/local/include</code>. + +<p><strong>Do not</strong> specify <code>/usr</code> as the <code>--with-local-prefix</code>! +The directory you use for <code>--with-local-prefix</code> <strong>must not</strong> +contain any of the system's standard header files. If it did contain +them, certain programs would be miscompiled (including GNU Emacs, on +certain targets), because this would override and nullify the header +file corrections made by the <code>fixincludes</code> script. + +<p>Indications are that people who use this option use it based on mistaken +ideas of what it is for. People use it as if it specified where to +install part of GCC. Perhaps they make this assumption because +installing GCC creates the directory. + +<br><dt><code>--enable-shared[=<var>package</var>[,<small>...</small>]]</code> +<dd>Build shared versions of libraries, if shared libraries are supported on +the target platform. Unlike GCC 2.95.x and earlier, shared libraries +are enabled by default on all platforms that support shared libraries, +except for <code>libobjc</code> which is built as a static library only by +default. + +<p>If a list of packages is given as an argument, build shared libraries +only for the listed packages. For other packages, only static libraries +will be built. Package names currently recognized in the GCC tree are +<code>libgcc</code> (also known as <code>gcc</code>), <code>libstdc++</code> (not +<code>libstdc++-v3</code>), <code>libffi</code>, <code>zlib</code>, <code>boehm-gc</code> and +<code>libjava</code>. Note that <code>libobjc</code> does not recognize itself by +any name, so, if you list package names in <code>--enable-shared</code>, +you will only get static Objective-C libraries. <code>libf2c</code> and +<code>libiberty</code> do not support shared libraries at all. + +<p>Use <code>--disable-shared</code> to build only static libraries. Note that +<code>--disable-shared</code> does not accept a list of package names as +argument, only <code>--enable-shared</code> does. + +<br><dt><code><a name="with-gnu-as"></a>--with-gnu-as</code> +<dd>Specify that the compiler should assume that the +assembler it finds is the GNU assembler. However, this does not modify +the rules to find an assembler and will result in confusion if the +assembler found is not actually the GNU assembler. (Confusion may also +result if the compiler finds the GNU assembler but has not been +configured with <code>--with-gnu-as</code>.) If you have more than one +assembler installed on your system, you may want to use this option in +connection with <code>--with-as=<var>pathname</var></code>. + +<p>The following systems are the only ones where it makes a difference +whether you use the GNU assembler. On any other system, +<code>--with-gnu-as</code> has no effect. + +<ul> +<li><code>hppa1.0-<var>any</var>-<var>any</var></code> +<li><code>hppa1.1-<var>any</var>-<var>any</var></code> +<li><code>i386-<var>any</var>-sysv</code> +<li><code>m68k-bull-sysv</code> +<li><code>m68k-hp-hpux</code> +<li><code>m68000-hp-hpux</code> +<li><code>m68000-att-sysv</code> +<li><code><var>any</var>-lynx-lynxos</code> +<li><code>mips-<var>any</var></code> +<li><code>sparc-sun-solaris2.<var>any</var></code> +<li><code>sparc64-<var>any</var>-solaris2.<var>any</var></code> +</ul> + +<p>On the systems listed above (except for the HP-PA, the SPARC, for ISC on +the 386, and for <code>mips-sgi-irix5.*</code>), if you use the GNU assembler, +you should also use the GNU linker (and specify <code>--with-gnu-ld</code>). + +<br><dt><code><a name="with-as"></a>--with-as=<var>pathname</var></code> +<dd>Specify that the +compiler should use the assembler pointed to by <var>pathname</var>, rather +than the one found by the standard rules to find an assembler, which +are: +<ul> +<li>Check the +<code><var>exec_prefix</var>/lib/gcc-lib/<var>target</var>/<var>version</var></code> +directory, where <var>exec_prefix</var> defaults to <var>prefix</var> which +defaults to <code>/usr/local</code> unless overridden by the +<code>--prefix=<var>pathname</var></code> switch described above. <var>target</var> is the +target system triple, such as <code>sparc-sun-solaris2.7</code>, and +<var>version</var> denotes the GCC version, such as 3.0. +<li>Check operating system specific directories (e.g. <code>/usr/ccs/bin</code> on +Sun Solaris 2). +</ul> +Note that these rules do not check for the value of <code>PATH</code>. You may +want to use <code>--with-as</code> if no assembler is installed in the +directories listed above, or if you have multiple assemblers installed +and want to choose one that is not found by the above rules. + +<br><dt><code><a name="with-gnu-ld"></a>--with-gnu-ld</code> +<dd>Same as <a href="#with-gnu-as"><code>--with-gnu-as</code></a> +but for the linker. + +<br><dt><code>--with-ld=<var>pathname</var></code> +<dd>Same as <a href="#with-as"><code>--with-as</code></a> +but for the linker. + +<br><dt><code>--with-stabs</code> +<dd>Specify that stabs debugging +information should be used instead of whatever format the host normally +uses. Normally GCC uses the same debug format as the host system. + +<p>On MIPS based systems and on Alphas, you must specify whether you want +GCC to create the normal ECOFF debugging format, or to use BSD-style +stabs passed through the ECOFF symbol table. The normal ECOFF debug +format cannot fully handle languages other than C. BSD stabs format can +handle other languages, but it only works with the GNU debugger GDB. + +<p>Normally, GCC uses the ECOFF debugging format by default; if you +prefer BSD stabs, specify <code>--with-stabs</code> when you configure GCC. + +<p>No matter which default you choose when you configure GCC, the user +can use the <code>-gcoff</code> and <code>-gstabs+</code> options to specify explicitly +the debug format for a particular compilation. + +<p><code>--with-stabs</code> is meaningful on the ISC system on the 386, also, if +<code>--with-gas</code> is used. It selects use of stabs debugging +information embedded in COFF output. This kind of debugging information +supports C++ well; ordinary COFF debugging information does not. + +<p><code>--with-stabs</code> is also meaningful on 386 systems running SVR4. It +selects use of stabs debugging information embedded in ELF output. The +C++ compiler currently (2.6.0) does not support the DWARF debugging +information normally used on 386 SVR4 platforms; stabs provide a +workable alternative. This requires gas and gdb, as the normal SVR4 +tools can not generate or interpret stabs. + +<br><dt><code>--disable-multilib</code> +<dd>Specify that multiple target +libraries to support different target variants, calling +conventions, etc should not be built. The default is to build a +predefined set of them. + +<p>Some targets provide finer-grained control over which multilibs are built +(e.g., <code>--disable-softfloat</code>): +<dl> +<dt><code>arc-*-elf*</code> +<dd>biendian. + +<br><dt><code>arm-*-*</code> +<dd>fpu, 26bit, underscore, interwork, biendian, nofmult. + +<br><dt><code>m68*-*-*</code> +<dd>softfloat, m68881, m68000, m68020. + +<br><dt><code>mips*-*-*</code> +<dd>single-float, biendian, softfloat. + +<br><dt><code>powerpc*-*-*, rs6000*-*-*</code> +<dd>aix64, pthread, softfloat, powercpu, powerpccpu, powerpcos, biendian, +sysv, aix. + +</dl> + +<br><dt><code>--enable-threads</code> +<dd>Specify that the target +supports threads. This affects the Objective-C compiler and runtime +library, and exception handling for other languages like C++ and Java. +On some systems, this is the default. + +<p>In general, the best (and, in many cases, the only known) threading +model available will be configured for use. Beware that on some +systems, gcc has not been taught what threading models are generally +available for the system. In this case, <code>--enable-threads</code> is an +alias for <code>--enable-threads=single</code>. + +<br><dt><code>--disable-threads</code> +<dd>Specify that threading support should be disabled for the system. +This is an alias for <code>--enable-threads=single</code>. + +<br><dt><code>--enable-threads=<var>lib</var></code> +<dd>Specify that +<var>lib</var> is the thread support library. This affects the Objective-C +compiler and runtime library, and exception handling for other languages +like C++ and Java. The possibilities for <var>lib</var> are: + +<dl> +<dt><code>aix</code> +<dd>AIX thread support. +<br><dt><code>dce</code> +<dd>DCE thread support. +<br><dt><code>mach</code> +<dd>Generic MACH thread support, known to work on NeXTSTEP. (Please note +that the file needed to support this configuration, <code>gthr-mach.h</code>, is +missing and thus this setting will cause a known bootstrap failure.) +<br><dt><code>no</code> +<dd>This is an alias for <code>single</code>. +<br><dt><code>posix</code> +<dd>Generic POSIX thread support. +<br><dt><code>pthreads</code> +<dd>Same as <code>posix</code> on arm*-*-linux*, *-*-chorusos* and *-*-freebsd* +only. A future release of gcc might remove this alias or extend it +to all platforms. +<br><dt><code>rtems</code> +<dd>RTEMS thread support. +<br><dt><code>single</code> +<dd>Disable thread support, should work for all platforms. +<br><dt><code>solaris</code> +<dd>Sun Solaris 2 thread support. +<br><dt><code>vxworks</code> +<dd>VxWorks thread support. +<br><dt><code>win32</code> +<dd>Microsoft Win32 API thread support. +</dl> + +<br><dt><code>--with-cpu=<var>cpu</var></code> +<dd>Specify which cpu variant the +compiler should generate code for by default. This is currently +only supported on some ports, specifically arm, powerpc, and +SPARC. If configure does not recognize the model name (e.g. arm700, +603e, or ultrasparc) you provide, please check the +<code>gcc/config.gcc</code> script for a complete list of supported models. + +<br><dt><code>--enable-altivec</code> +<dd>Specify that the target supports AltiVec vector enhancements. This +option will adjust the ABI for AltiVec enhancements, as well as generate +AltiVec code when appropriate. This option is only available for +PowerPC systems. + +<br><dt><code>--enable-target-optspace</code> +<dd>Specify that target +libraries should be optimized for code space instead of code speed. +This is the default for the m32r platform. + +<br><dt><code>--disable-cpp</code> +<dd>Specify that a user visible <code>cpp</code> program should not be installed. + +<br><dt><code>--with-cpp-install-dir=<var>dirname</var></code> +<dd>Specify that the user visible <code>cpp</code> program should be installed +in <code><var>prefix</var>/<var>dirname</var>/cpp</code>, in addition to <var>bindir</var>. + +<br><dt><code>--enable-initfini-array</code> +<dd>Force the use of sections <code>.init_array</code> and <code>.fini_array</code> +(instead of <code>.init</code> and <code>.fini</code>) for constructors and +destructors. Option <code>--disable-initfini-array</code> has the +opposite effect. If neither option is specified, the configure script +will try to guess whether the <code>.init_array</code> and +<code>.fini_array</code> sections are supported and, if they are, use them. + +<br><dt><code>--enable-maintainer-mode</code> +<dd>The build rules that +regenerate the GCC master message catalog <code>gcc.pot</code> are normally +disabled. This is because it can only be rebuilt if the complete source +tree is present. If you have changed the sources and want to rebuild the +catalog, configuring with <code>--enable-maintainer-mode</code> will enable +this. Note that you need a recent version of the <code>gettext</code> tools +to do so. + +<br><dt><code>--enable-version-specific-runtime-libs</code> +<dd>Specify +that runtime libraries should be installed in the compiler specific +subdirectory (<code><var>libsubdir</var></code>) rather than the usual places. In +addition, <code>libstdc++</code>'s include files will be installed in +<code><var>libsubdir</var>/include/g++</code> unless you overruled it by using +<code>--with-gxx-include-dir=<var>dirname</var></code>. Using this option is +particularly useful if you intend to use several versions of GCC in +parallel. This is currently supported by <code>libf2c</code> and +<code>libstdc++</code>, and is the default for <code>libobjc</code> which cannot be +changed in this case. + +<br><dt><code>--enable-languages=<var>lang1</var>,<var>lang2</var>,<small>...</small></code> +<dd>Specify that only a particular subset of compilers and +their runtime libraries should be built. For a list of valid values for +<var>langN</var> you can issue the following command in the +<code>gcc</code> directory of your GCC source tree:<br> +<br><pre>grep language= */config-lang.in +</pre> +Currently, you can use any of the following: +<code>ada</code>, <code>c</code>, <code>c++</code>, <code>f77</code>, <code>java</code>, <code>objc</code>. +Building the Ada compiler has special requirements, see below.<br> +If you do not pass this flag, all languages available in the <code>gcc</code> +sub-tree will be configured. Re-defining <code>LANGUAGES</code> when calling +<code>make bootstrap</code> <strong>does not</strong> work anymore, as those +language sub-directories might not have been configured! + +<br><dt><code>--disable-libgcj</code> +<dd>Specify that the run-time libraries +used by GCJ should not be built. This is useful in case you intend +to use GCJ with some other run-time, or you're going to install it +separately, or it just happens not to build on your particular +machine. In general, if the Java front end is enabled, the GCJ +libraries will be enabled too, unless they're known to not work on +the target platform. If GCJ is enabled but <code>libgcj</code> isn't built, you +may need to port it; in this case, before modifying the top-level +<code>configure.in</code> so that <code>libgcj</code> is enabled by default on this platform, +you may use <code>--enable-libgcj</code> to override the default. + +<br><dt><code>--with-dwarf2</code> +<dd>Specify that the compiler should +use DWARF 2 debugging information as the default. + +<br><dt><code>--enable-win32-registry</code> +<dt><code>--enable-win32-registry=<var>key</var></code> +<dt><code>--disable-win32-registry</code> +<dd>The <code>--enable-win32-registry</code> option enables Windows-hosted GCC +to look up installations paths in the registry using the following key: + +<br><pre><code>HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\<var>key</var></code> +</pre> + +<p><var>key</var> defaults to GCC version number, and can be overridden by the +<code>--enable-win32-registry=<var>key</var></code> option. Vendors and distributors +who use custom installers are encouraged to provide a different key, +perhaps one comprised of vendor name and GCC version number, to +avoid conflict with existing installations. This feature is enabled +by default, and can be disabled by <code>--disable-win32-registry</code> +option. This option has no effect on the other hosts. + +<br><dt><code>--nfp</code> +<dd>Specify that the machine does not have a floating point unit. This +option only applies to <code>m68k-sun-sunos<var>n</var></code>. On any other +system, <code>--nfp</code> has no effect. + +<br><dt><code>--enable-checking</code> +<dt><code>--enable-checking=<var>list</var></code> +<dd>When you specify this option, the compiler is built to perform checking +of tree node types when referencing fields of that node, and some other +internal consistency checks. This does not change the generated code, +but adds error checking within the compiler. This will slow down the +compiler and may only work properly if you are building the compiler +with GCC. This is on by default when building from CVS or snapshots, +but off for releases. More control over the checks may be had by +specifying <var>list</var>; the categories of checks available are +<code>misc</code>, <code>tree</code>, <code>gc</code>, <code>rtl</code>, <code>rtlflag</code>, +<code>gcac</code> and <code>valgrind</code>. The check <code>valgrind</code> requires the +external <code>valgrind</code> simulator, available from +<a href="http://developer.kde.org/~sewardj/">http://developer.kde.org/~sewardj/</a>. The default when <var>list</var> is +not specified is <code>misc,tree,gc,rtlflag</code>; the checks <code>rtl</code>, +<code>gcac</code> and <code>valgrind</code> are very expensive. + +<br><dt><code>--enable-coverage</code> +<br><dt><code>--enable-coverage=<var>level</var></code> +<dd>With this option, the compiler is built to collect self coverage +information, every time it is run. This is for internal development +purposes, and only works when the compiler is being built with gcc. The +<var>level</var> argument controls whether the compiler is built optimized or +not, values are <code>opt</code> and <code>noopt</code>. For coverage analysis you +want to disable optimization, for performance analysis you want to +enable optimization. When coverage is enabled, the default level is +without optimization. + +<br><dt><code>--enable-nls</code> +<dt><code>--disable-nls</code> +<dd>The <code>--enable-nls</code> option enables Native Language Support (NLS), +which lets GCC output diagnostics in languages other than American +English. Native Language Support is enabled by default if not doing a +canadian cross build. The <code>--disable-nls</code> option disables NLS. + +<br><dt><code>--with-included-gettext</code> +<dd>If NLS is enabled, the <code>--with-included-gettext</code> option causes the build +procedure to prefer its copy of GNU <code>gettext</code>. + +<br><dt><code>--with-catgets</code> +<dd>If NLS is enabled, and if the host lacks <code>gettext</code> but has the +inferior <code>catgets</code> interface, the GCC build procedure normally +ignores <code>catgets</code> and instead uses GCC's copy of the GNU +<code>gettext</code> library. The <code>--with-catgets</code> option causes the +build procedure to use the host's <code>catgets</code> in this situation. + +<br><dt><code>--with-libiconv-prefix=<var>dir</var></code> +<dd>Search for libiconv header files in <code><var>dir</var>/include</code> and +libiconv library files in <code><var>dir</var>/lib</code>. + +<br><dt><code>--with-system-zlib</code> +<dd>Use installed zlib rather than that included with GCC. This option +only applies if the Java front end is being built. + +<br><dt><code>--enable-obsolete</code> +<dd>Enable configuration for an obsoleted system. If you attempt to +configure GCC for a system (build, host, or target) which has been +obsoleted, and you do not specify this flag, configure will halt with an +error message. + +<p>All support for systems which have been obsoleted in one release of GCC +is removed entirely in the next major release, unless someone steps +forward to maintain the port. +</dl> + +<p>Some options which only apply to building cross compilers: +<dl> +<dt><code>--with-headers</code> +<dt><code>--with-headers=<var>dir</var></code> +<dd>Specifies that target headers are available when building a cross compiler. +The <var>dir</var> argument specifies a directory which has the target include +files. These include files will be copied into the <code>gcc</code> install +directory. <em>This option with the <var>dir</var> argument is required</em> when +building a cross compiler, if <code><var>prefix</var>/<var>target</var>/sys-include</code> +doesn't pre-exist. If <code><var>prefix</var>/<var>target</var>/sys-include</code> does +pre-exist, the <var>dir</var> argument may be omitted. <code>fixincludes</code> +will be run on these files to make them compatible with GCC. +<br><dt><code>--with-libs</code> +<dt><code>--with-libs=``<var>dir1</var> <var>dir2</var> <small>...</small> <var>dirN</var>''</code> +<dd>Specifies a list of directories which contain the target runtime +libraries. These libraries will be copied into the <code>gcc</code> install +directory. If the directory list is omitted, this option has no +effect. +<br><dt><code>--with-newlib</code> +<dd>Specifies that <code>newlib</code> is +being used as the target C library. This causes <code>__eprintf</code> to be +omitted from <code>libgcc.a</code> on the assumption that it will be provided by +<code>newlib</code>. +</dl> + +<p>Note that each <code>--enable</code> option has a corresponding +<code>--disable</code> option and that each <code>--with</code> option has a +corresponding <code>--without</code> option. + +<hr /> +<p> +<a href="./index.html">Return to the GCC Installation page</a> + +</body></html> + diff --git a/gnu/usr.bin/gcc/INSTALL/download.html b/gnu/usr.bin/gcc/INSTALL/download.html new file mode 100644 index 00000000000..469477d68e9 --- /dev/null +++ b/gnu/usr.bin/gcc/INSTALL/download.html @@ -0,0 +1,67 @@ +<html lang="en"> +<head> +<title>Downloading GCC</title> +<meta http-equiv="Content-Type" content="text/html"> +<meta name=description content="Downloading GCC"> +<meta name=generator content="makeinfo 4.2"> +<link href="http://www.gnu.org/software/texinfo/" rel=generator-home> +<!-- +Copyright © 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, +1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc. +<br><p> +<p>Permission is granted to copy, distribute and/or modify this document +under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no +Invariant Sections, the Front-Cover texts being (a) (see below), and +with the Back-Cover Texts being (b) (see below). A copy of the +license is included in the section entitled "<a href="./gfdl.html">GNU Free Documentation License</a>". + +<p>(a) The FSF's Front-Cover Text is: + +<p>A GNU Manual + +<p>(b) The FSF's Back-Cover Text is: + +<p>You have freedom to copy and modify this GNU Manual, like GNU + software. Copies published by the Free Software Foundation raise + funds for GNU development.--> +</head> +<body> +<h1>Downloading GCC</h1> +GCC is distributed via <a href="http://gcc.gnu.org/cvs.html">CVS</a> and FTP +tarballs compressed with <code>gzip</code> or +<code>bzip2</code>. It is possible to download a full distribution or specific +components. + +<p>Please refer to our <a href="http://gcc.gnu.org/releases.html">releases web page</a> +for information on how to obtain GCC. + +<p>The full distribution includes the C, C++, Objective-C, Fortran, Java, +and Ada (in case of GCC 3.1 and later) compilers. The full distribution +also includes runtime libraries for C++, Objective-C, Fortran, and Java. +In GCC 3.0 and later versions, GNU compiler testsuites are also included +in the full distribution. + +<p>If you choose to download specific components, you must download the core +GCC distribution plus any language specific distributions you wish to +use. The core distribution includes the C language front end as well as the +shared components. Each language has a tarball which includes the language +front end as well as the language runtime (when appropriate). + +<p>Unpack the core distribution as well as any language specific +distributions in the same directory. + +<p>If you also intend to build binutils (either to upgrade an existing +installation or for use in place of the corresponding tools of your +OS), unpack the binutils distribution either in the same directory or +a separate one. In the latter case, add symbolic links to any +components of the binutils you intend to build alongside the compiler +(<code>bfd</code>, <code>binutils</code>, <code>gas</code>, <code>gprof</code>, <code>ld</code>, +<code>opcodes</code>, <small>...</small>) to the directory containing the GCC sources. + +<hr /> +<p> +<a href="./index.html">Return to the GCC Installation page</a> + +</body></html> + diff --git a/gnu/usr.bin/gcc/INSTALL/finalinstall.html b/gnu/usr.bin/gcc/INSTALL/finalinstall.html new file mode 100644 index 00000000000..deef09371aa --- /dev/null +++ b/gnu/usr.bin/gcc/INSTALL/finalinstall.html @@ -0,0 +1,141 @@ +<html lang="en"> +<head> +<title>Installing GCC: Final installation</title> +<meta http-equiv="Content-Type" content="text/html"> +<meta name=description content="Installing GCC: Final installation"> +<meta name=generator content="makeinfo 4.2"> +<link href="http://www.gnu.org/software/texinfo/" rel=generator-home> +<!-- +Copyright © 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, +1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc. +<br><p> +<p>Permission is granted to copy, distribute and/or modify this document +under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no +Invariant Sections, the Front-Cover texts being (a) (see below), and +with the Back-Cover Texts being (b) (see below). A copy of the +license is included in the section entitled "<a href="./gfdl.html">GNU Free Documentation License</a>". + +<p>(a) The FSF's Front-Cover Text is: + +<p>A GNU Manual + +<p>(b) The FSF's Back-Cover Text is: + +<p>You have freedom to copy and modify this GNU Manual, like GNU + software. Copies published by the Free Software Foundation raise + funds for GNU development.--> +</head> +<body> +<h1>Installing GCC: Final installation</h1> +Now that GCC has been built (and optionally tested), you can install it with +<br><pre>cd <var>objdir</var>; make install +</pre> + +<p>We strongly recommend to install into a target directory where there is +no previous version of GCC present. + +<p>That step completes the installation of GCC; user level binaries can +be found in <code><var>prefix</var>/bin</code> where <var>prefix</var> is the value you +specified with the <code>--prefix</code> to configure (or <code>/usr/local</code> +by default). (If you specified <code>--bindir</code>, that directory will +be used instead; otherwise, if you specified <code>--exec-prefix</code>, +<code><var>exec-prefix</var>/bin</code> will be used.) Headers for the C++ and +Java libraries are installed in <code><var>prefix</var>/include</code>; libraries +in <code><var>libdir</var></code> (normally <code><var>prefix</var>/lib</code>); internal +parts of the compiler in <code><var>libdir</var>/gcc-lib</code>; documentation in +info format in <code><var>infodir</var></code> (normally <code><var>prefix</var>/info</code>). + +<p>When installing cross-compilers, GCC's executables +are not only installed into <code><var>bindir</var></code>, that +is, <code><var>exec-prefix</var>/bin</code>, but additionally into +<code><var>exec-prefix</var>/<var>target-alias</var>/bin</code>, if that directory +exists. Typically, such <dfn>tooldirs</dfn> hold target-specific +binutils, including assembler and linker. + +<p>Installation into a temporary staging area or into a <code>chroot</code> +jail can be achieved with the command + +<br><pre>make DESTDIR=<var>path-to-rootdir</var> install +</pre> + +<p>where <var>path-to-rootdir</var> is the absolute path of +a directory relative to which all installation paths will be +interpreted. Note that the directory specified by <code>DESTDIR</code> +need not exist yet; it will be created if necessary. + +<p>There is a subtle point with tooldirs and <code>DESTDIR</code>: +If you relocate a cross-compiler installation with +e.g. <code>DESTDIR=<var>rootdir</var></code>, then the directory +<code><var>rootdir</var>/<var>exec-prefix</var>/<var>target-alias</var>/bin</code> will +be filled with duplicated GCC executables only if it already exists, +it will not be created otherwise. This is regarded as a feature, +not as a bug, because it gives slightly more control to the packagers +using the <code>DESTDIR</code> feature. + +<p>If you built a released version of GCC using <code>make bootstrap</code> then please +quickly review the build status page for your release, available from +<a href="http://gcc.gnu.org/buildstat.html">http://gcc.gnu.org/buildstat.html</a>. +If your system is not listed for the version of GCC that you built, +send a note to +<a href="mailto:gcc@gcc.gnu.org">gcc@gcc.gnu.org</a> indicating +that you successfully built and installed GCC. +Include the following information: + +<ul> +<li>Output from running <code><var>srcdir</var>/config.guess</code>. Do not send us +that file itself, just the one-line output from running it. + +<li>The output of <code>gcc -v</code> for your newly installed gcc. +This tells us which version of GCC you built and the options you passed to +configure. + +<li>Whether you enabled all languages or a subset of them. If you used a +full distribution then this information is part of the configure +options in the output of <code>gcc -v</code>, but if you downloaded the +"core" compiler plus additional front ends then it isn't apparent +which ones you built unless you tell us about it. + +<li>If the build was for GNU/Linux, also include: +<ul> +<li>The distribution name and version (e.g., Red Hat 7.1 or Debian 2.2.3); +this information should be available from <code>/etc/issue</code>. + +<li>The version of the Linux kernel, available from <code>uname --version</code> +or <code>uname -a</code>. + +<li>The version of glibc you used; for RPM-based systems like Red Hat, +Mandrake, and SuSE type <code>rpm -q glibc</code> to get the glibc version, +and on systems like Debian and Progeny use <code>dpkg -l libc6</code>. +</ul> +For other systems, you can include similar information if you think it is +relevant. + +<li>Any other information that you think would be useful to people building +GCC on the same configuration. The new entry in the build status list +will include a link to the archived copy of your message. +</ul> + +<p>We'd also like to know if the +<a href="specific.html">host/target specific installation notes</a> +didn't include your host/target information or if that information is +incomplete or out of date. Send a note to +<a href="mailto:gcc@gcc.gnu.org">gcc@gcc.gnu.org</a> telling us how the information should be changed. + +<p>If you find a bug, please report it following our +<a href="../bugs.html">bug reporting guidelines</a>. + +<p>If you want to print the GCC manuals, do <code>cd <var>objdir</var>; make +dvi</code>. You will need to have <code>texi2dvi</code> (version at least 4.2) +and TeX installed. This creates a number of <code>.dvi</code> files in +subdirectories of <code><var>objdir</var></code>; these may be converted for +printing with programs such as <code>dvips</code>. You can also +<a href="http://www.gnu.org/order/order.html">buy printed manuals from the Free Software Foundation</a>, though such manuals may not be for the most +recent version of GCC. + +<hr /> +<p> +<a href="./index.html">Return to the GCC Installation page</a> + +</body></html> + diff --git a/gnu/usr.bin/gcc/INSTALL/gfdl.html b/gnu/usr.bin/gcc/INSTALL/gfdl.html new file mode 100644 index 00000000000..e0b3465ac1a --- /dev/null +++ b/gnu/usr.bin/gcc/INSTALL/gfdl.html @@ -0,0 +1,446 @@ +<html lang="en"> +<head> +<title>Installing GCC: GNU Free Documentation License</title> +<meta http-equiv="Content-Type" content="text/html"> +<meta name=description content="Installing GCC: GNU Free Documentation License"> +<meta name=generator content="makeinfo 4.2"> +<link href="http://www.gnu.org/software/texinfo/" rel=generator-home> +<!-- +Copyright © 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, +1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc. +<br><p> +<p>Permission is granted to copy, distribute and/or modify this document +under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no +Invariant Sections, the Front-Cover texts being (a) (see below), and +with the Back-Cover Texts being (b) (see below). A copy of the +license is included in the section entitled "<a href="./gfdl.html">GNU Free Documentation License</a>". + +<p>(a) The FSF's Front-Cover Text is: + +<p>A GNU Manual + +<p>(b) The FSF's Back-Cover Text is: + +<p>You have freedom to copy and modify this GNU Manual, like GNU + software. Copies published by the Free Software Foundation raise + funds for GNU development.--> +</head> +<body> +<h1>Installing GCC: GNU Free Documentation License</h1> +<h1 align="center">Installing GCC: GNU Free Documentation License</h1> + +<div align="center">Version 1.2, November 2002</div> +<br><pre>Copyright © 2000,2001,2002 Free Software Foundation, Inc. +59 Temple Place, Suite 330, Boston, MA 02111-1307, USA + +Everyone is permitted to copy and distribute verbatim copies +of this license document, but changing it is not allowed. +</pre> + +<ol type=1 start=0> +</p><li>PREAMBLE + +<p>The purpose of this License is to make a manual, textbook, or other +functional and useful document <dfn>free</dfn> in the sense of freedom: to +assure everyone the effective freedom to copy and redistribute it, +with or without modifying it, either commercially or noncommercially. +Secondarily, this License preserves for the author and publisher a way +to get credit for their work, while not being considered responsible +for modifications made by others. + +<p>This License is a kind of "copyleft", which means that derivative +works of the document must themselves be free in the same sense. It +complements the GNU General Public License, which is a copyleft +license designed for free software. + +<p>We have designed this License in order to use it for manuals for free +software, because free software needs free documentation: a free +program should come with manuals providing the same freedoms that the +software does. But this License is not limited to software manuals; +it can be used for any textual work, regardless of subject matter or +whether it is published as a printed book. We recommend this License +principally for works whose purpose is instruction or reference. + +</p><li>APPLICABILITY AND DEFINITIONS + +<p>This License applies to any manual or other work, in any medium, that +contains a notice placed by the copyright holder saying it can be +distributed under the terms of this License. Such a notice grants a +world-wide, royalty-free license, unlimited in duration, to use that +work under the conditions stated herein. The "Document", below, +refers to any such manual or work. Any member of the public is a +licensee, and is addressed as "you". You accept the license if you +copy, modify or distribute the work in a way requiring permission +under copyright law. + +<p>A "Modified Version" of the Document means any work containing the +Document or a portion of it, either copied verbatim, or with +modifications and/or translated into another language. + +<p>A "Secondary Section" is a named appendix or a front-matter section +of the Document that deals exclusively with the relationship of the +publishers or authors of the Document to the Document's overall +subject (or to related matters) and contains nothing that could fall +directly within that overall subject. (Thus, if the Document is in +part a textbook of mathematics, a Secondary Section may not explain +any mathematics.) The relationship could be a matter of historical +connection with the subject or with related matters, or of legal, +commercial, philosophical, ethical or political position regarding +them. + +<p>The "Invariant Sections" are certain Secondary Sections whose titles +are designated, as being those of Invariant Sections, in the notice +that says that the Document is released under this License. If a +section does not fit the above definition of Secondary then it is not +allowed to be designated as Invariant. The Document may contain zero +Invariant Sections. If the Document does not identify any Invariant +Sections then there are none. + +<p>The "Cover Texts" are certain short passages of text that are listed, +as Front-Cover Texts or Back-Cover Texts, in the notice that says that +the Document is released under this License. A Front-Cover Text may +be at most 5 words, and a Back-Cover Text may be at most 25 words. + +<p>A "Transparent" copy of the Document means a machine-readable copy, +represented in a format whose specification is available to the +general public, that is suitable for revising the document +straightforwardly with generic text editors or (for images composed of +pixels) generic paint programs or (for drawings) some widely available +drawing editor, and that is suitable for input to text formatters or +for automatic translation to a variety of formats suitable for input +to text formatters. A copy made in an otherwise Transparent file +format whose markup, or absence of markup, has been arranged to thwart +or discourage subsequent modification by readers is not Transparent. +An image format is not Transparent if used for any substantial amount +of text. A copy that is not "Transparent" is called "Opaque". + +<p>Examples of suitable formats for Transparent copies include plain +<small>ASCII</small> without markup, Texinfo input format, LaTeX input +format, <small>SGML</small> or <small>XML</small> using a publicly available +<small>DTD</small>, and standard-conforming simple <small>HTML</small>, +PostScript or <small>PDF</small> designed for human modification. Examples +of transparent image formats include <small>PNG</small>, <small>XCF</small> and +<small>JPG</small>. Opaque formats include proprietary formats that can be +read and edited only by proprietary word processors, <small>SGML</small> or +<small>XML</small> for which the <small>DTD</small> and/or processing tools are +not generally available, and the machine-generated <small>HTML</small>, +PostScript or <small>PDF</small> produced by some word processors for +output purposes only. + +<p>The "Title Page" means, for a printed book, the title page itself, +plus such following pages as are needed to hold, legibly, the material +this License requires to appear in the title page. For works in +formats which do not have any title page as such, "Title Page" means +the text near the most prominent appearance of the work's title, +preceding the beginning of the body of the text. + +<p>A section "Entitled XYZ" means a named subunit of the Document whose +title either is precisely XYZ or contains XYZ in parentheses following +text that translates XYZ in another language. (Here XYZ stands for a +specific section name mentioned below, such as "Acknowledgements", +"Dedications", "Endorsements", or "History".) To "Preserve the Title" +of such a section when you modify the Document means that it remains a +section "Entitled XYZ" according to this definition. + +<p>The Document may include Warranty Disclaimers next to the notice which +states that this License applies to the Document. These Warranty +Disclaimers are considered to be included by reference in this +License, but only as regards disclaiming warranties: any other +implication that these Warranty Disclaimers may have is void and has +no effect on the meaning of this License. + +</p><li>VERBATIM COPYING + +<p>You may copy and distribute the Document in any medium, either +commercially or noncommercially, provided that this License, the +copyright notices, and the license notice saying this License applies +to the Document are reproduced in all copies, and that you add no other +conditions whatsoever to those of this License. You may not use +technical measures to obstruct or control the reading or further +copying of the copies you make or distribute. However, you may accept +compensation in exchange for copies. If you distribute a large enough +number of copies you must also follow the conditions in section 3. + +<p>You may also lend copies, under the same conditions stated above, and +you may publicly display copies. + +</p><li>COPYING IN QUANTITY + +<p>If you publish printed copies (or copies in media that commonly have +printed covers) of the Document, numbering more than 100, and the +Document's license notice requires Cover Texts, you must enclose the +copies in covers that carry, clearly and legibly, all these Cover +Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on +the back cover. Both covers must also clearly and legibly identify +you as the publisher of these copies. The front cover must present +the full title with all words of the title equally prominent and +visible. You may add other material on the covers in addition. +Copying with changes limited to the covers, as long as they preserve +the title of the Document and satisfy these conditions, can be treated +as verbatim copying in other respects. + +<p>If the required texts for either cover are too voluminous to fit +legibly, you should put the first ones listed (as many as fit +reasonably) on the actual cover, and continue the rest onto adjacent +pages. + +<p>If you publish or distribute Opaque copies of the Document numbering +more than 100, you must either include a machine-readable Transparent +copy along with each Opaque copy, or state in or with each Opaque copy +a computer-network location from which the general network-using +public has access to download using public-standard network protocols +a complete Transparent copy of the Document, free of added material. +If you use the latter option, you must take reasonably prudent steps, +when you begin distribution of Opaque copies in quantity, to ensure +that this Transparent copy will remain thus accessible at the stated +location until at least one year after the last time you distribute an +Opaque copy (directly or through your agents or retailers) of that +edition to the public. + +<p>It is requested, but not required, that you contact the authors of the +Document well before redistributing any large number of copies, to give +them a chance to provide you with an updated version of the Document. + +</p><li>MODIFICATIONS + +<p>You may copy and distribute a Modified Version of the Document under +the conditions of sections 2 and 3 above, provided that you release +the Modified Version under precisely this License, with the Modified +Version filling the role of the Document, thus licensing distribution +and modification of the Modified Version to whoever possesses a copy +of it. In addition, you must do these things in the Modified Version: + +<ol type=A start=1> +</p><li>Use in the Title Page (and on the covers, if any) a title distinct +from that of the Document, and from those of previous versions +(which should, if there were any, be listed in the History section +of the Document). You may use the same title as a previous version +if the original publisher of that version gives permission. + +<li>List on the Title Page, as authors, one or more persons or entities +responsible for authorship of the modifications in the Modified +Version, together with at least five of the principal authors of the +Document (all of its principal authors, if it has fewer than five), +unless they release you from this requirement. + +<li>State on the Title page the name of the publisher of the +Modified Version, as the publisher. + +<li>Preserve all the copyright notices of the Document. + +<li>Add an appropriate copyright notice for your modifications +adjacent to the other copyright notices. + +<li>Include, immediately after the copyright notices, a license notice +giving the public permission to use the Modified Version under the +terms of this License, in the form shown in the Addendum below. + +<li>Preserve in that license notice the full lists of Invariant Sections +and required Cover Texts given in the Document's license notice. + +<li>Include an unaltered copy of this License. + +<li>Preserve the section Entitled "History", Preserve its Title, and add +to it an item stating at least the title, year, new authors, and +publisher of the Modified Version as given on the Title Page. If +there is no section Entitled "History" in the Document, create one +stating the title, year, authors, and publisher of the Document as +given on its Title Page, then add an item describing the Modified +Version as stated in the previous sentence. + +<li>Preserve the network location, if any, given in the Document for +public access to a Transparent copy of the Document, and likewise +the network locations given in the Document for previous versions +it was based on. These may be placed in the "History" section. +You may omit a network location for a work that was published at +least four years before the Document itself, or if the original +publisher of the version it refers to gives permission. + +<li>For any section Entitled "Acknowledgements" or "Dedications", Preserve +the Title of the section, and preserve in the section all the +substance and tone of each of the contributor acknowledgements and/or +dedications given therein. + +<li>Preserve all the Invariant Sections of the Document, +unaltered in their text and in their titles. Section numbers +or the equivalent are not considered part of the section titles. + +<li>Delete any section Entitled "Endorsements". Such a section +may not be included in the Modified Version. + +<li>Do not retitle any existing section to be Entitled "Endorsements" or +to conflict in title with any Invariant Section. + +<li>Preserve any Warranty Disclaimers. +</ol> + +<p>If the Modified Version includes new front-matter sections or +appendices that qualify as Secondary Sections and contain no material +copied from the Document, you may at your option designate some or all +of these sections as invariant. To do this, add their titles to the +list of Invariant Sections in the Modified Version's license notice. +These titles must be distinct from any other section titles. + +<p>You may add a section Entitled "Endorsements", provided it contains +nothing but endorsements of your Modified Version by various +parties--for example, statements of peer review or that the text has +been approved by an organization as the authoritative definition of a +standard. + +<p>You may add a passage of up to five words as a Front-Cover Text, and a +passage of up to 25 words as a Back-Cover Text, to the end of the list +of Cover Texts in the Modified Version. Only one passage of +Front-Cover Text and one of Back-Cover Text may be added by (or +through arrangements made by) any one entity. If the Document already +includes a cover text for the same cover, previously added by you or +by arrangement made by the same entity you are acting on behalf of, +you may not add another; but you may replace the old one, on explicit +permission from the previous publisher that added the old one. + +<p>The author(s) and publisher(s) of the Document do not by this License +give permission to use their names for publicity for or to assert or +imply endorsement of any Modified Version. + +</p><li>COMBINING DOCUMENTS + +<p>You may combine the Document with other documents released under this +License, under the terms defined in section 4 above for modified +versions, provided that you include in the combination all of the +Invariant Sections of all of the original documents, unmodified, and +list them all as Invariant Sections of your combined work in its +license notice, and that you preserve all their Warranty Disclaimers. + +<p>The combined work need only contain one copy of this License, and +multiple identical Invariant Sections may be replaced with a single +copy. If there are multiple Invariant Sections with the same name but +different contents, make the title of each such section unique by +adding at the end of it, in parentheses, the name of the original +author or publisher of that section if known, or else a unique number. +Make the same adjustment to the section titles in the list of +Invariant Sections in the license notice of the combined work. + +<p>In the combination, you must combine any sections Entitled "History" +in the various original documents, forming one section Entitled +"History"; likewise combine any sections Entitled "Acknowledgements", +and any sections Entitled "Dedications". You must delete all +sections Entitled "Endorsements." + +</p><li>COLLECTIONS OF DOCUMENTS + +<p>You may make a collection consisting of the Document and other documents +released under this License, and replace the individual copies of this +License in the various documents with a single copy that is included in +the collection, provided that you follow the rules of this License for +verbatim copying of each of the documents in all other respects. + +<p>You may extract a single document from such a collection, and distribute +it individually under this License, provided you insert a copy of this +License into the extracted document, and follow this License in all +other respects regarding verbatim copying of that document. + +</p><li>AGGREGATION WITH INDEPENDENT WORKS + +<p>A compilation of the Document or its derivatives with other separate +and independent documents or works, in or on a volume of a storage or +distribution medium, is called an "aggregate" if the copyright +resulting from the compilation is not used to limit the legal rights +of the compilation's users beyond what the individual works permit. +When the Document is included an aggregate, this License does not +apply to the other works in the aggregate which are not themselves +derivative works of the Document. + +<p>If the Cover Text requirement of section 3 is applicable to these +copies of the Document, then if the Document is less than one half of +the entire aggregate, the Document's Cover Texts may be placed on +covers that bracket the Document within the aggregate, or the +electronic equivalent of covers if the Document is in electronic form. +Otherwise they must appear on printed covers that bracket the whole +aggregate. + +</p><li>TRANSLATION + +<p>Translation is considered a kind of modification, so you may +distribute translations of the Document under the terms of section 4. +Replacing Invariant Sections with translations requires special +permission from their copyright holders, but you may include +translations of some or all Invariant Sections in addition to the +original versions of these Invariant Sections. You may include a +translation of this License, and all the license notices in the +Document, and any Warrany Disclaimers, provided that you also include +the original English version of this License and the original versions +of those notices and disclaimers. In case of a disagreement between +the translation and the original version of this License or a notice +or disclaimer, the original version will prevail. + +<p>If a section in the Document is Entitled "Acknowledgements", +"Dedications", or "History", the requirement (section 4) to Preserve +its Title (section 1) will typically require changing the actual +title. + +</p><li>TERMINATION + +<p>You may not copy, modify, sublicense, or distribute the Document except +as expressly provided for under this License. Any other attempt to +copy, modify, sublicense or distribute the Document is void, and will +automatically terminate your rights under this License. However, +parties who have received copies, or rights, from you under this +License will not have their licenses terminated so long as such +parties remain in full compliance. + +</p><li>FUTURE REVISIONS OF THIS LICENSE + +<p>The Free Software Foundation may publish new, revised versions +of the GNU Free Documentation License from time to time. Such new +versions will be similar in spirit to the present version, but may +differ in detail to address new problems or concerns. See +<a href="http://www.gnu.org/copyleft/">http://www.gnu.org/copyleft/</a>. + +<p>Each version of the License is given a distinguishing version number. +If the Document specifies that a particular numbered version of this +License "or any later version" applies to it, you have the option of +following the terms and conditions either of that specified version or +of any later version that has been published (not as a draft) by the +Free Software Foundation. If the Document does not specify a version +number of this License, you may choose any version ever published (not +as a draft) by the Free Software Foundation. +</ol> + +<h3><a name="TOC0"></a>ADDENDUM: How to use this License for your documents</h3> + +<p>To use this License in a document you have written, include a copy of +the License in the document and put the following copyright and +license notices just after the title page: + +<br><pre> Copyright (C) <var>year</var> <var>your name</var>. + Permission is granted to copy, distribute and/or modify this document + under the terms of the GNU Free Documentation License, Version 1.2 + or any later version published by the Free Software Foundation; + with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. + A copy of the license is included in the section entitled ``GNU + Free Documentation License''. +</pre> + +<p>If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, +replace the "with...Texts." line with this: + +<br><pre> with the Invariant Sections being <var>list their titles</var>, with + the Front-Cover Texts being <var>list</var>, and with the Back-Cover Texts + being <var>list</var>. +</pre> + +<p>If you have Invariant Sections without Cover Texts, or some other +combination of the three, merge those two alternatives to suit the +situation. + +<p>If your document contains nontrivial examples of program code, we +recommend releasing these examples in parallel under your choice of +free software license, such as the GNU General Public License, +to permit their use in free software. + +<hr /> +<p> +<a href="./index.html">Return to the GCC Installation page</a> + +</body></html> + diff --git a/gnu/usr.bin/gcc/INSTALL/index.html b/gnu/usr.bin/gcc/INSTALL/index.html new file mode 100644 index 00000000000..97ef25421d0 --- /dev/null +++ b/gnu/usr.bin/gcc/INSTALL/index.html @@ -0,0 +1,95 @@ +<html lang="en"> +<head> +<title>Installing GCC</title> +<meta http-equiv="Content-Type" content="text/html"> +<meta name=description content="Installing GCC"> +<meta name=generator content="makeinfo 4.2"> +<link href="http://www.gnu.org/software/texinfo/" rel=generator-home> +<!-- +Copyright © 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, +1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc. +<br><p> +<p>Permission is granted to copy, distribute and/or modify this document +under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no +Invariant Sections, the Front-Cover texts being (a) (see below), and +with the Back-Cover Texts being (b) (see below). A copy of the +license is included in the section entitled "<a href="./gfdl.html">GNU Free Documentation License</a>". + +<p>(a) The FSF's Front-Cover Text is: + +<p>A GNU Manual + +<p>(b) The FSF's Back-Cover Text is: + +<p>You have freedom to copy and modify this GNU Manual, like GNU + software. Copies published by the Free Software Foundation raise + funds for GNU development.--> +</head> +<body> +<h1>Installing GCC</h1> +The latest version of this document is always available at +<a href="http://gcc.gnu.org/install/">http://gcc.gnu.org/install/</a>. + +<p>This document describes the generic installation procedure for GCC as well +as detailing some target specific installation instructions. + +<p>GCC includes several components that previously were separate distributions +with their own installation instructions. This document supersedes all +package specific installation instructions. + +<p><em>Before</em> starting the build/install procedure please check the +<a href="specific.html">host/target specific installation notes</a>. +We recommend you browse the entire generic installation instructions before +you proceed. + +<p>Lists of successful builds for released versions of GCC are +available at <a href="http://gcc.gnu.org/buildstat.html">http://gcc.gnu.org/buildstat.html</a>. +These lists are updated as new information becomes available. + +<p>The installation procedure itself is broken into five steps. + +<ol type=1 start=1> +</p><li><a href="download.html">Downloading the source</a> +<li><a href="configure.html">Configuration</a> +<li><a href="build.html">Building</a> +<li><a href="test.html">Testing</a> (optional) +<li><a href="finalinstall.html">Final install</a> +</ol> + +<p>Please note that GCC does not support <code>make uninstall</code> and probably +won't do so in the near future as this would open a can of worms. Instead, +we suggest that you install GCC into a directory of its own and simply +remove that directory when you do not need that specific version of GCC +any longer, and, if shared libraries are installed there as well, no +more binaries exist that use them. + +<p>There are also some <a href="old.html">old installation instructions</a>, +which are mostly obsolete but still contain some information which has +not yet been merged into the main part of this manual. + +<hr /> +<p> +<a href="./index.html">Return to the GCC Installation page</a> + +Copyright © 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, +1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc. +<br><p> +<p>Permission is granted to copy, distribute and/or modify this document +under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no +Invariant Sections, the Front-Cover texts being (a) (see below), and +with the Back-Cover Texts being (b) (see below). A copy of the +license is included in the section entitled "<a href="./gfdl.html">GNU Free Documentation License</a>". + +<p>(a) The FSF's Front-Cover Text is: + +<p>A GNU Manual + +<p>(b) The FSF's Back-Cover Text is: + +<p>You have freedom to copy and modify this GNU Manual, like GNU + software. Copies published by the Free Software Foundation raise + funds for GNU development. +</body></html> + diff --git a/gnu/usr.bin/gcc/INSTALL/old.html b/gnu/usr.bin/gcc/INSTALL/old.html new file mode 100644 index 00000000000..220d523a1c2 --- /dev/null +++ b/gnu/usr.bin/gcc/INSTALL/old.html @@ -0,0 +1,618 @@ +<html lang="en"> +<head> +<title>Installing GCC: Old documentation</title> +<meta http-equiv="Content-Type" content="text/html"> +<meta name=description content="Installing GCC: Old documentation"> +<meta name=generator content="makeinfo 4.2"> +<link href="http://www.gnu.org/software/texinfo/" rel=generator-home> +<!-- +Copyright © 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, +1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc. +<br><p> +<p>Permission is granted to copy, distribute and/or modify this document +under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no +Invariant Sections, the Front-Cover texts being (a) (see below), and +with the Back-Cover Texts being (b) (see below). A copy of the +license is included in the section entitled "<a href="./gfdl.html">GNU Free Documentation License</a>". + +<p>(a) The FSF's Front-Cover Text is: + +<p>A GNU Manual + +<p>(b) The FSF's Back-Cover Text is: + +<p>You have freedom to copy and modify this GNU Manual, like GNU + software. Copies published by the Free Software Foundation raise + funds for GNU development.--> +</head> +<body> +<h1>Installing GCC: Old documentation</h1> +<h1 align="center">Old installation documentation</h1> + +<p>Note most of this information is out of date and superseded by the +previous chapters of this manual. It is provided for historical +reference only, because of a lack of volunteers to merge it into the +main manual. + +<p>Here is the procedure for installing GNU CC on a GNU or Unix system. +See <a href="#VMS%20Install">VMS Install</a>, for VMS systems. + +<ol type=1 start=1> +</p><li>If you have chosen a configuration for GNU CC 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 +<code>as</code>, <code>ld</code> or whatever is appropriate. + +<p>Alternatively, you can do subsequent compilation using a value of the +<code>PATH</code> environment variable such that the necessary GNU tools come +before the standard system tools. + +</p><li>Specify the host, build and target machine configurations. You do this +when you run the <code>configure</code> script. + +<p>The <dfn>build</dfn> machine is the system which you are using, the +<dfn>host</dfn> machine is the system where you want to run the resulting +compiler (normally the build machine), and the <dfn>target</dfn> machine is +the system for which you want the compiler to generate code. + +<p>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 <code>configure</code>; 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 +<code>configure</code> cannot figure out what your configuration is or guesses +wrong. + +<p>In those cases, specify the build machine's <dfn>configuration name</dfn> +with the <code>--host</code> option; the host and target will default to be +the same as the host machine. (If you are building a cross-compiler, +see <a href="#Cross-Compiler">Cross-Compiler</a>.) + +<p>Here is an example: + +<br><pre>./configure --host=sparc-sun-sunos4.1 +</pre> + +<p>A configuration name may be canonical or it may be more or less +abbreviated. + +<p>A canonical configuration name has three parts, separated by dashes. +It looks like this: <code><var>cpu</var>-<var>company</var>-<var>system</var></code>. +(The three parts may themselves contain dashes; <code>configure</code> +can figure out which dashes serve which purpose.) For example, +<code>m68k-sun-sunos4.1</code> specifies a Sun 3. + +<p>You can also replace parts of the configuration by nicknames or aliases. +For example, <code>sun3</code> stands for <code>m68k-sun</code>, so +<code>sun3-sunos4.1</code> is another way to specify a Sun 3. + +<p>You can specify a version number after any of the system types, and some +of the CPU types. In most cases, the version is irrelevant, and will be +ignored. So you might as well specify the version if you know it. + +<p>See <a href="#Configurations">Configurations</a>, for a list of supported configuration names and +notes on many of the configurations. You should check the notes in that +section before proceeding any further with the installation of GNU CC. + +</ol> + +<h2><a name="Configurations"></a>Configurations Supported by GNU CC</h2> + +<p>Here are the possible CPU types: + +<blockquote> +1750a, a29k, alpha, arm, avr, c<var>n</var>, clipper, dsp16xx, elxsi, fr30, h8300, +hppa1.0, hppa1.1, i370, i386, i486, i586, i686, i786, i860, i960, ip2k, m32r, +m68000, m68k, m6811, m6812, m88k, mcore, mips, mipsel, mips64, mips64el, +mn10200, mn10300, ns32k, pdp11, powerpc, powerpcle, romp, rs6000, sh, sparc, +sparclite, sparc64, v850, vax, we32k. +</blockquote> + +<p>Here are the recognized company names. As you can see, customary +abbreviations are used rather than the longer official names. + +<blockquote> +acorn, alliant, altos, apollo, apple, att, bull, +cbm, convergent, convex, crds, dec, dg, dolphin, +elxsi, encore, harris, hitachi, hp, ibm, intergraph, isi, +mips, motorola, ncr, next, ns, omron, plexus, +sequent, sgi, sony, sun, tti, unicom, wrs. +</blockquote> + +<p>The company name is meaningful only to disambiguate when the rest of +the information supplied is insufficient. You can omit it, writing +just <code><var>cpu</var>-<var>system</var></code>, if it is not needed. For example, +<code>vax-ultrix4.2</code> is equivalent to <code>vax-dec-ultrix4.2</code>. + +<p>Here is a list of system types: + +<blockquote> +386bsd, aix, acis, amigaos, aos, aout, aux, bosx, bsd, clix, coff, ctix, cxux, +dgux, dynix, ebmon, ecoff, elf, esix, freebsd, hms, genix, gnu, linux, +linux-gnu, hiux, hpux, iris, irix, isc, luna, lynxos, mach, minix, msdos, mvs, +netbsd, newsos, nindy, ns, osf, osfrose, ptx, riscix, riscos, rtu, sco, sim, +solaris, sunos, sym, sysv, udi, ultrix, unicos, uniplus, unos, vms, vsta, +vxworks, winnt, xenix. +</blockquote> + +<p>You can omit the system type; then <code>configure</code> guesses the +operating system from the CPU and company. + +<p>You can add a version number to the system type; this may or may not +make a difference. For example, you can write <code>bsd4.3</code> or +<code>bsd4.4</code> to distinguish versions of BSD. In practice, the version +number is most needed for <code>sysv3</code> and <code>sysv4</code>, which are often +treated differently. + +<p><code>linux-gnu</code> is the canonical name for the GNU/Linux target; however +GNU CC will also accept <code>linux</code>. The version of the kernel in use is +not relevant on these systems. A suffix such as <code>libc1</code> or <code>aout</code> +distinguishes major versions of the C library; all of the suffixed versions +are obsolete. + +<p>If you specify an impossible combination such as <code>i860-dg-vms</code>, +then you may get an error message from <code>configure</code>, or it may +ignore part of the information and do the best it can with the rest. +<code>configure</code> always prints the canonical name for the alternative +that it used. GNU CC does not support all possible alternatives. + +<p>Often a particular model of machine has a name. Many machine names are +recognized as aliases for CPU/company combinations. Thus, the machine +name <code>sun3</code>, mentioned above, is an alias for <code>m68k-sun</code>. +Sometimes we accept a company name as a machine name, when the name is +popularly used for a particular machine. Here is a table of the known +machine names: + +<blockquote> +3300, 3b1, 3b<var>n</var>, 7300, altos3068, altos, +apollo68, att-7300, balance, +convex-c<var>n</var>, crds, decstation-3100, +decstation, delta, encore, +fx2800, gmicro, hp7<var>nn</var>, hp8<var>nn</var>, +hp9k2<var>nn</var>, hp9k3<var>nn</var>, hp9k7<var>nn</var>, +hp9k8<var>nn</var>, iris4d, iris, isi68, +m3230, magnum, merlin, miniframe, +mmax, news-3600, news800, news, next, +pbd, pc532, pmax, powerpc, powerpcle, ps2, risc-news, +rtpc, sun2, sun386i, sun386, sun3, +sun4, symmetry, tower-32, tower. +</blockquote> + +<p>Remember that a machine name specifies both the cpu type and the company +name. +If you want to install your own homemade configuration files, you can +use <code>local</code> as the company name to access them. If you use +configuration <code><var>cpu</var>-local</code>, the configuration name +without the cpu prefix +is used to form the configuration file names. + +<p>Thus, if you specify <code>m68k-local</code>, configuration uses +files <code>m68k.md</code>, <code>local.h</code>, <code>m68k.c</code>, +<code>xm-local.h</code>, <code>t-local</code>, and <code>x-local</code>, all in the +directory <code>config/m68k</code>. + +<p>Here is a list of configurations that have special treatment or special +things you must know: + +<dl> +<dt><code>vax-dec-vms</code> +<dd>See <a href="#VMS%20Install">VMS Install</a>, for details on how to install GNU CC on VMS. +</dl> + +<h2><a name="Cross-Compiler"></a>Building and Installing a Cross-Compiler</h2> + +<p>GNU CC can function as a cross-compiler for many machines, but not all. + +<ul> +<li>Cross-compilers for the Mips as target using the Mips assembler +currently do not work, because the auxiliary programs +<code>mips-tdump.c</code> and <code>mips-tfile.c</code> can't be compiled on +anything but a Mips. It does work to cross compile for a Mips +if you use the GNU assembler and linker. + +<li>Cross-compilers between machines with different floating point formats +have not all been made to work. GNU CC now has a floating point +emulator with which these can work, but each target machine description +needs to be updated to take advantage of it. + +<li>Cross-compilation between machines of different word sizes is +somewhat problematic and sometimes does not work. +</ul> + +<p>Since GNU CC generates assembler code, you probably need a +cross-assembler that GNU CC can run, in order to produce object files. +If you want to link on other than the target machine, you need a +cross-linker as well. You also need header files and libraries suitable +for the target machine that you can install on the host machine. + +<h2>Steps of Cross-Compilation</h2> + +<p>To compile and run a program using a cross-compiler involves several +steps: + +<ul> +<li>Run the cross-compiler on the host machine to produce assembler files +for the target machine. This requires header files for the target +machine. + +<li>Assemble the files produced by the cross-compiler. You can do this +either with an assembler on the target machine, or with a +cross-assembler on the host machine. + +<li>Link those files to make an executable. You can do this either with a +linker on the target machine, or with a cross-linker on the host +machine. Whichever machine you use, you need libraries and certain +startup files (typically <code>crt<small>...</small>.o</code>) for the target machine. +</ul> + +<p>It is most convenient to do all of these steps on the same host machine, +since then you can do it all with a single invocation of GNU CC. This +requires a suitable cross-assembler and cross-linker. For some targets, +the GNU assembler and linker are available. + +<h2>Configuring a Cross-Compiler</h2> + +<p>To build GNU CC as a cross-compiler, you start out by running +<code>configure</code>. Use the <code>--target=<var>target</var></code> to specify the +target type. If <code>configure</code> was unable to correctly identify the +system you are running on, also specify the <code>--build=<var>build</var></code> +option. For example, here is how to configure for a cross-compiler that +produces code for an HP 68030 system running BSD on a system that +<code>configure</code> can correctly identify: + +<br><pre>./configure --target=m68k-hp-bsd4.3 +</pre> + +<h2>Tools and Libraries for a Cross-Compiler</h2> + +<p>If you have a cross-assembler and cross-linker available, you should +install them now. Put them in the directory +<code>/usr/local/<var>target</var>/bin</code>. Here is a table of the tools +you should put in this directory: + +<dl> +<dt><code>as</code> +<dd>This should be the cross-assembler. + +<br><dt><code>ld</code> +<dd>This should be the cross-linker. + +<br><dt><code>ar</code> +<dd>This should be the cross-archiver: a program which can manipulate +archive files (linker libraries) in the target machine's format. + +<br><dt><code>ranlib</code> +<dd>This should be a program to construct a symbol table in an archive file. +</dl> + +<p>The installation of GNU CC will find these programs in that directory, +and copy or link them to the proper place to for the cross-compiler to +find them when run later. + +<p>The easiest way to provide these files is to build the Binutils package +and GAS. Configure them with the same <code>--host</code> and <code>--target</code> +options that you use for configuring GNU CC, then build and install +them. They install their executables automatically into the proper +directory. Alas, they do not support all the targets that GNU CC +supports. + +<p>If you want to install libraries to use with the cross-compiler, such as +a standard C library, put them in the directory +<code>/usr/local/<var>target</var>/lib</code>; installation of GNU CC copies +all the files in that subdirectory into the proper place for GNU CC to +find them and link with them. Here's an example of copying some +libraries from a target machine: + +<br><pre>ftp <var>target-machine</var> +lcd /usr/local/<var>target</var>/lib +cd /lib +get libc.a +cd /usr/lib +get libg.a +get libm.a +quit +</pre> + +<p>The precise set of libraries you'll need, and their locations on +the target machine, vary depending on its operating system. + +<p>Many targets require "start files" such as <code>crt0.o</code> and +<code>crtn.o</code> which are linked into each executable; these too should be +placed in <code>/usr/local/<var>target</var>/lib</code>. There may be several +alternatives for <code>crt0.o</code>, for use with profiling or other +compilation options. Check your target's definition of +<code>STARTFILE_SPEC</code> to find out what start files it uses. +Here's an example of copying these files from a target machine: + +<br><pre>ftp <var>target-machine</var> +lcd /usr/local/<var>target</var>/lib +prompt +cd /lib +mget *crt*.o +cd /usr/lib +mget *crt*.o +quit +</pre> + +<h2>Cross-Compilers and Header Files</h2> + +<p>If you are cross-compiling a standalone program or a program for an +embedded system, then you may not need any header files except the few +that are part of GNU CC (and those of your program). However, if you +intend to link your program with a standard C library such as +<code>libc.a</code>, then you probably need to compile with the header files +that go with the library you use. + +<p>The GNU C compiler does not come with these files, because (1) they are +system-specific, and (2) they belong in a C library, not in a compiler. + +<p>If the GNU C library supports your target machine, then you can get the +header files from there (assuming you actually use the GNU library when +you link your program). + +<p>If your target machine comes with a C compiler, it probably comes with +suitable header files also. If you make these files accessible from the host +machine, the cross-compiler can use them also. + +<p>Otherwise, you're on your own in finding header files to use when +cross-compiling. + +<p>When you have found suitable header files, you should put them in the +directory <code>/usr/local/<var>target</var>/include</code>, before building the +cross compiler. Then installation will run fixincludes properly and +install the corrected versions of the header files where the compiler +will use them. + +<p>Provide the header files before you build the cross-compiler, because +the build stage actually runs the cross-compiler to produce parts of +<code>libgcc.a</code>. (These are the parts that <em>can</em> be compiled with +GNU CC.) Some of them need suitable header files. + +<p>Here's an example showing how to copy the header files from a target +machine. On the target machine, do this: + +<br><pre>(cd /usr/include; tar cf - .) > tarfile +</pre> + +<p>Then, on the host machine, do this: + +<br><pre>ftp <var>target-machine</var> +lcd /usr/local/<var>target</var>/include +get tarfile +quit +tar xf tarfile +</pre> + +<h2>Actually Building the Cross-Compiler</h2> + +<p>Now you can proceed just as for compiling a single-machine compiler +through the step of building stage 1. + +<p>Do not try to build stage 2 for a cross-compiler. It doesn't work to +rebuild GNU CC as a cross-compiler using the cross-compiler, because +that would produce a program that runs on the target machine, not on the +host. For example, if you compile a 386-to-68030 cross-compiler with +itself, the result will not be right either for the 386 (because it was +compiled into 68030 code) or for the 68030 (because it was configured +for a 386 as the host). If you want to compile GNU CC into 68030 code, +whether you compile it on a 68030 or with a cross-compiler on a 386, you +must specify a 68030 as the host when you configure it. + +<p>To install the cross-compiler, use <code>make install</code>, as usual. + +<h2><a name="VMS%20Install"></a>Installing GNU CC on VMS</h2> + +<p>The VMS version of GNU CC is distributed in a backup saveset containing +both source code and precompiled binaries. + +<p>To install the <code>gcc</code> command so you can use the compiler easily, in +the same manner as you use the VMS C compiler, you must install the VMS CLD +file for GNU CC as follows: + +<ol type=1 start=1> +</p><li>Define the VMS logical names <code>GNU_CC</code> and <code>GNU_CC_INCLUDE</code> +to point to the directories where the GNU CC executables +(<code>gcc-cpp.exe</code>, <code>gcc-cc1.exe</code>, etc.) and the C include files are +kept respectively. This should be done with the commands: + +<br><pre>$ assign /system /translation=concealed - + disk:[gcc.] gnu_cc +$ assign /system /translation=concealed - + disk:[gcc.include.] gnu_cc_include +</pre> + +<p>with the appropriate disk and directory names. These commands can be +placed in your system startup file so they will be executed whenever +the machine is rebooted. You may, if you choose, do this via the +<code>GCC_INSTALL.COM</code> script in the <code>[GCC]</code> directory. + +</p><li>Install the <code>GCC</code> command with the command line: + +<br><pre>$ set command /table=sys$common:[syslib]dcltables - + /output=sys$common:[syslib]dcltables gnu_cc:[000000]gcc +$ install replace sys$common:[syslib]dcltables +</pre> + +<li>To install the help file, do the following: + +<br><pre>$ library/help sys$library:helplib.hlb gcc.hlp +</pre> + +<p>Now you can invoke the compiler with a command like <code>gcc /verbose +file.c</code>, which is equivalent to the command <code>gcc -v -c file.c</code> in +Unix. +</ol> + +<p>If you wish to use GNU C++ you must first install GNU CC, and then +perform the following steps: + +<ol type=1 start=1> +</p><li>Define the VMS logical name <code>GNU_GXX_INCLUDE</code> to point to the +directory where the preprocessor will search for the C++ header files. +This can be done with the command: + +<br><pre>$ assign /system /translation=concealed - + disk:[gcc.gxx_include.] gnu_gxx_include +</pre> + +<p>with the appropriate disk and directory name. If you are going to be +using a C++ runtime library, this is where its install procedure will install +its header files. + +</p><li>Obtain the file <code>gcc-cc1plus.exe</code>, and place this in the same +directory that <code>gcc-cc1.exe</code> is kept. + +<p>The GNU C++ compiler can be invoked with a command like <code>gcc /plus +/verbose file.cc</code>, which is equivalent to the command <code>g++ -v -c +file.cc</code> in Unix. +</ol> + +<p>We try to put corresponding binaries and sources on the VMS distribution +tape. But sometimes the binaries will be from an older version than the +sources, because we don't always have time to update them. (Use the +<code>/version</code> option to determine the version number of the binaries and +compare it with the source file <code>version.c</code> to tell whether this is +so.) In this case, you should use the binaries you get to recompile the +sources. If you must recompile, here is how: + +<ol type=1 start=1> +</p><li>Execute the command procedure <code>vmsconfig.com</code> to set up the files +<code>tm.h</code>, <code>config.h</code>, <code>aux-output.c</code>, and <code>md.</code>, and +to create files <code>tconfig.h</code> and <code>hconfig.h</code>. This procedure +also creates several linker option files used by <code>make-cc1.com</code> and +a data file used by <code>make-l2.com</code>. + +<br><pre>$ @vmsconfig.com +</pre> + +<li>Setup the logical names and command tables as defined above. In +addition, define the VMS logical name <code>GNU_BISON</code> to point at the +to the directories where the Bison executable is kept. This should be +done with the command: + +<br><pre>$ assign /system /translation=concealed - + disk:[bison.] gnu_bison +</pre> + +<p>You may, if you choose, use the <code>INSTALL_BISON.COM</code> script in the +<code>[BISON]</code> directory. + +</p><li>Install the <code>BISON</code> command with the command line: + +<br><pre>$ set command /table=sys$common:[syslib]dcltables - + /output=sys$common:[syslib]dcltables - + gnu_bison:[000000]bison +$ install replace sys$common:[syslib]dcltables +</pre> + +<li>Type <code>@make-gcc</code> to recompile everything, or submit the file +<code>make-gcc.com</code> to a batch queue. If you wish to build the GNU C++ +compiler as well as the GNU CC compiler, you must first edit +<code>make-gcc.com</code> and follow the instructions that appear in the +comments. + +<li>In order to use GCC, you need a library of functions which GCC compiled code +will call to perform certain tasks, and these functions are defined in the +file <code>libgcc2.c</code>. To compile this you should use the command procedure +<code>make-l2.com</code>, which will generate the library <code>libgcc2.olb</code>. +<code>libgcc2.olb</code> should be built using the compiler built from +the same distribution that <code>libgcc2.c</code> came from, and +<code>make-gcc.com</code> will automatically do all of this for you. + +<p>To install the library, use the following commands: + +<br><pre>$ library gnu_cc:[000000]gcclib/delete=(new,eprintf) +$ library gnu_cc:[000000]gcclib/delete=L_* +$ library libgcc2/extract=*/output=libgcc2.obj +$ library gnu_cc:[000000]gcclib libgcc2.obj +</pre> + +<p>The first command simply removes old modules that will be replaced with +modules from <code>libgcc2</code> under different module names. The modules +<code>new</code> and <code>eprintf</code> may not actually be present in your +<code>gcclib.olb</code>--if the VMS librarian complains about those modules +not being present, simply ignore the message and continue on with the +next command. The second command removes the modules that came from the +previous version of the library <code>libgcc2.c</code>. + +<p>Whenever you update the compiler on your system, you should also update the +library with the above procedure. + +</p><li>You may wish to build GCC in such a way that no files are written to the +directory where the source files reside. An example would be the when +the source files are on a read-only disk. In these cases, execute the +following DCL commands (substituting your actual path names): + +<br><pre>$ assign dua0:[gcc.build_dir.]/translation=concealed, - + dua1:[gcc.source_dir.]/translation=concealed gcc_build +$ set default gcc_build:[000000] +</pre> + +<p>where the directory <code>dua1:[gcc.source_dir]</code> contains the source +code, and the directory <code>dua0:[gcc.build_dir]</code> is meant to contain +all of the generated object files and executables. Once you have done +this, you can proceed building GCC as described above. (Keep in mind +that <code>gcc_build</code> is a rooted logical name, and thus the device +names in each element of the search list must be an actual physical +device name rather than another rooted logical name). + +</p><li><strong>If you are building GNU CC with a previous version of GNU CC, +you also should check to see that you have the newest version of the +assembler</strong>. In particular, GNU CC version 2 treats global constant +variables slightly differently from GNU CC version 1, and GAS version +1.38.1 does not have the patches required to work with GCC version 2. +If you use GAS 1.38.1, then <code>extern const</code> variables will not have +the read-only bit set, and the linker will generate warning messages +about mismatched psect attributes for these variables. These warning +messages are merely a nuisance, and can safely be ignored. + +<li>If you want to build GNU CC with the VAX C compiler, you will need to +make minor changes in <code>make-cccp.com</code> and <code>make-cc1.com</code> +to choose alternate definitions of <code>CC</code>, <code>CFLAGS</code>, and +<code>LIBS</code>. See comments in those files. However, you must +also have a working version of the GNU assembler (GNU as, aka GAS) as +it is used as the back end for GNU CC to produce binary object modules +and is not included in the GNU CC sources. GAS is also needed to +compile <code>libgcc2</code> in order to build <code>gcclib</code> (see above); +<code>make-l2.com</code> expects to be able to find it operational in +<code>gnu_cc:[000000]gnu-as.exe</code>. + +<p>To use GNU CC on VMS, you need the VMS driver programs +<code>gcc.exe</code>, <code>gcc.com</code>, and <code>gcc.cld</code>. They are +distributed with the VMS binaries (<code>gcc-vms</code>) rather than the +GNU CC sources. GAS is also included in <code>gcc-vms</code>, as is Bison. + +<p>Once you have successfully built GNU CC with VAX C, you should use the +resulting compiler to rebuild itself. Before doing this, be sure to +restore the <code>CC</code>, <code>CFLAGS</code>, and <code>LIBS</code> definitions in +<code>make-cccp.com</code> and <code>make-cc1.com</code>. The second generation +compiler will be able to take advantage of many optimizations that must +be suppressed when building with other compilers. +</ol> + +<p>Under previous versions of GNU CC, the generated code would occasionally +give strange results when linked with the sharable <code>VAXCRTL</code> library. +Now this should work. + +<p>Even with this version, however, GNU CC itself should not be linked with +the sharable <code>VAXCRTL</code>. The version of <code>qsort</code> in +<code>VAXCRTL</code> has a bug (known to be present in VMS versions V4.6 +through V5.5) which causes the compiler to fail. + +<p>The executables are generated by <code>make-cc1.com</code> and +<code>make-cccp.com</code> use the object library version of <code>VAXCRTL</code> in +order to make use of the <code>qsort</code> routine in <code>gcclib.olb</code>. If +you wish to link the compiler executables with the shareable image +version of <code>VAXCRTL</code>, you should edit the file <code>tm.h</code> (created +by <code>vmsconfig.com</code>) to define the macro <code>QSORT_WORKAROUND</code>. + +<p><code>QSORT_WORKAROUND</code> is always defined when GNU CC is compiled with +VAX C, to avoid a problem in case <code>gcclib.olb</code> is not yet +available. +<hr /> +<p> +<a href="./index.html">Return to the GCC Installation page</a> + +</body></html> + diff --git a/gnu/usr.bin/gcc/INSTALL/specific.html b/gnu/usr.bin/gcc/INSTALL/specific.html new file mode 100644 index 00000000000..7f4c2891b71 --- /dev/null +++ b/gnu/usr.bin/gcc/INSTALL/specific.html @@ -0,0 +1,1665 @@ +<html lang="en"> +<head> +<title>Host/Target specific installation notes for GCC</title> +<meta http-equiv="Content-Type" content="text/html"> +<meta name=description content="Host/Target specific installation notes for GCC"> +<meta name=generator content="makeinfo 4.2"> +<link href="http://www.gnu.org/software/texinfo/" rel=generator-home> +<!-- +Copyright © 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, +1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc. +<br><p> +<p>Permission is granted to copy, distribute and/or modify this document +under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no +Invariant Sections, the Front-Cover texts being (a) (see below), and +with the Back-Cover Texts being (b) (see below). A copy of the +license is included in the section entitled "<a href="./gfdl.html">GNU Free Documentation License</a>". + +<p>(a) The FSF's Front-Cover Text is: + +<p>A GNU Manual + +<p>(b) The FSF's Back-Cover Text is: + +<p>You have freedom to copy and modify this GNU Manual, like GNU + software. Copies published by the Free Software Foundation raise + funds for GNU development.--> +</head> +<body> +<h1>Host/Target specific installation notes for GCC</h1> +Please read this document carefully <em>before</em> installing the +GNU Compiler Collection on your machine. + +<ul> +<li><a href="#alpha*-*-*">alpha*-*-*</a> +<li><a href="#alpha*-dec-osf*">alpha*-dec-osf*</a> +<li><a href="#alphaev5-cray-unicosmk*">alphaev5-cray-unicosmk*</a> +<li><a href="#arc-*-elf">arc-*-elf</a> +<li><a href="#arm-*-aout">arm-*-aout</a> +<li><a href="#arm-*-elf">arm-*-elf</a> +<li><a href="#arm*-*-linux-gnu">arm*-*-linux-gnu</a> +<li><a href="#avr">avr</a> +<li><a href="#c4x">c4x</a> +<li><a href="#dos">DOS</a> +<li><a href="#dsp16xx">dsp16xx</a> +<li><a href="#*-*-freebsd*">*-*-freebsd*</a> +<li><a href="#h8300-hms">h8300-hms</a> +<li><a href="#hppa*-hp-hpux*">hppa*-hp-hpux*</a> +<li><a href="#hppa*-hp-hpux9">hppa*-hp-hpux9</a> +<li><a href="#hppa*-hp-hpux10">hppa*-hp-hpux10</a> +<li><a href="#hppa*-hp-hpux11">hppa*-hp-hpux11</a> +<li><a href="#i370-*-*">i370-*-*</a> +<li><a href="#*-*-linux-gnu">*-*-linux-gnu</a> +<li><a href="#ix86-*-linux*aout">i?86-*-linux*aout</a> +<li><a href="#ix86-*-linux*">i?86-*-linux*</a> +<li><a href="#ix86-*-sco">i?86-*-sco</a> +<li><a href="#ix86-*-sco3.2v4">i?86-*-sco3.2v4</a> +<li><a href="#ix86-*-sco3.2v5*">i?86-*-sco3.2v5*</a> +<li><a href="#ix86-*-udk">i?86-*-udk</a> +<li><a href="#ix86-*-esix">i?86-*-esix</a> +<li><a href="#ia64-*-linux">ia64-*-linux</a> +<li><a href="#ia64-*-hpux*">ia64-*-hpux*</a> +<li><a href="#*-lynx-lynxos">*-lynx-lynxos</a> +<li><a href="#*-ibm-aix*">*-ibm-aix*</a> +<li><a href="#ip2k-*-elf">ip2k-*-elf</a> +<li><a href="#m32r-*-elf">m32r-*-elf</a> +<li><a href="#m68000-hp-bsd">m68000-hp-bsd</a> +<li><a href="#m6811-elf">m6811-elf</a> +<li><a href="#m6812-elf">m6812-elf</a> +<li><a href="#m68k-att-sysv">m68k-att-sysv</a> +<li><a href="#m68k-crds-unos">m68k-crds-unos</a> +<li><a href="#m68k-hp-hpux">m68k-hp-hpux</a> +<li><a href="#m68k-ncr-*">m68k-ncr-*</a> +<li><a href="#m68k-sun">m68k-sun</a> +<li><a href="#m68k-sun-sunos4.1.1">m68k-sun-sunos4.1.1</a> +<li><a href="#mips-*-*">mips-*-*</a> +<li><a href="#mips-sgi-irix5">mips-sgi-irix5</a> +<li><a href="#mips-sgi-irix6">mips-sgi-irix6</a> +<li><a href="#powerpc*-*-*">powerpc*-*-*</a> powerpc-*-sysv4 +<li><a href="#powerpc-*-darwin*">powerpc-*-darwin*</a> +<li><a href="#powerpc-*-elf">powerpc-*-elf</a> powerpc-*-sysv4 +<li><a href="#powerpc-*-linux-gnu*">powerpc-*-linux-gnu*</a> +<li><a href="#powerpc-*-netbsd*">powerpc-*-netbsd*</a> +<li><a href="#powerpc-*-eabiaix">powerpc-*-eabiaix</a> +<li><a href="#powerpc-*-eabisim">powerpc-*-eabisim</a> +<li><a href="#powerpc-*-eabi">powerpc-*-eabi</a> +<li><a href="#powerpcle-*-elf">powerpcle-*-elf</a> powerpcle-*-sysv4 +<li><a href="#powerpcle-*-eabisim">powerpcle-*-eabisim</a> +<li><a href="#powerpcle-*-eabi">powerpcle-*-eabi</a> +<li><a href="#s390-*-linux*">s390-*-linux*</a> +<li><a href="#s390x-*-linux*">s390x-*-linux*</a> +<li><a href="#*-*-solaris2*">*-*-solaris2*</a> +<li><a href="#sparc-sun-solaris2*">sparc-sun-solaris2*</a> +<li><a href="#sparc-sun-solaris2.7">sparc-sun-solaris2.7</a> +<li><a href="#sparc-sun-sunos4*">sparc-sun-sunos4*</a> +<li><a href="#sparc-unknown-linux-gnulibc1">sparc-unknown-linux-gnulibc1</a> +<li><a href="#sparc-*-linux*">sparc-*-linux*</a> +<li><a href="#sparc64-*-solaris2*">sparc64-*-solaris2*</a> +<li><a href="#sparcv9-*-solaris2*">sparcv9-*-solaris2*</a> +<li><a href="#*-*-sysv*">*-*-sysv*</a> +<li><a href="#vax-dec-ultrix">vax-dec-ultrix</a> +<li><a href="#xtensa-*-elf">xtensa-*-elf</a> +<li><a href="#xtensa-*-linux*">xtensa-*-linux*</a> +<li><a href="#windows">Microsoft Windows</a> +<li><a href="#os2">OS/2</a> +<li><a href="#older">Older systems</a> +</ul> + +<ul> +<li><a href="#elf_targets">all ELF targets</a> (SVR4, Solaris 2, etc.) +</ul> + +<!- ------- host/target specific issues start here --------------- -> +<hr /> + +<h3><a name="TOC0"></a><a name="alpha*-*-*"></a>alpha*-*-*</h3> + +<p>This section contains general configuration information for all +alpha-based platforms using ELF (in particular, ignore this section for +DEC OSF/1, Digital UNIX and Tru64 UNIX). In addition to reading this +section, please read all other sections that match your target. + +<p>We require binutils 2.11.2 or newer. +Previous binutils releases had a number of problems with DWARF 2 +debugging information, not the least of which is incorrect linking of +shared libraries. + +<hr /> + +<h3><a name="TOC1"></a><a name="alpha*-dec-osf*"></a>alpha*-dec-osf*</h3> + +<p>Systems using processors that implement the DEC Alpha architecture and +are running the DEC/Compaq Unix (DEC OSF/1, Digital UNIX, or Compaq +Tru64 UNIX) operating system, for example the DEC Alpha AXP systems. + +<p>As of GCC 3.2, versions before <code>alpha*-dec-osf4</code> are no longer +supported. (These are the versions which identify themselves as DEC +OSF/1.) + +<p>In Digital Unix V4.0, virtual memory exhausted bootstrap failures +may be fixed by configuring with <code>--with-gc=simple</code>, +reconfiguring Kernel Virtual Memory and Swap parameters +per the <code>/usr/sbin/sys_check</code> Tuning Suggestions, +or applying the patch in +<a href="http://gcc.gnu.org/ml/gcc/2002-08/msg00822.html">http://gcc.gnu.org/ml/gcc/2002-08/msg00822.html</a>. + +<p>In Tru64 UNIX V5.1, Compaq introduced a new assembler that does not +currently (2001-06-13) work with <code>mips-tfile</code>. As a workaround, +we need to use the old assembler, invoked via the barely documented +<code>-oldas</code> option. To bootstrap GCC, you either need to use the +Compaq C Compiler: + +<br><pre> % CC=cc <var>srcdir</var>/configure [<var>options</var>] [<var>target</var>] +</pre> + +<p>or you can use a copy of GCC 2.95.3 or higher built on Tru64 UNIX V4.0: + +<br><pre> % CC=gcc -Wa,-oldas <var>srcdir</var>/configure [<var>options</var>] [<var>target</var>] +</pre> + +<p>As of GNU binutils 2.11.2, neither GNU <code>as</code> nor GNU <code>ld</code> +are supported on Tru64 UNIX, so you must not configure GCC with +<code>--with-gnu-as</code> or <code>--with-gnu-ld</code>. + +<p>The <code>--enable-threads</code> options isn't supported yet. A patch is +in preparation for a future release. + +<p>GCC writes a <code>.verstamp</code> directive to the assembler output file +unless it is built as a cross-compiler. It gets the version to use from +the system header file <code>/usr/include/stamp.h</code>. If you install a +new version of DEC Unix, you should rebuild GCC to pick up the new version +stamp. + +<p>Note that since the Alpha is a 64-bit architecture, cross-compilers from +32-bit machines will not generate code as efficient as that generated +when the compiler is running on a 64-bit machine because many +optimizations that depend on being able to represent a word on the +target in an integral value on the host cannot be performed. Building +cross-compilers on the Alpha for 32-bit machines has only been tested in +a few cases and may not work properly. + +<p><code>make compare</code> may fail on old versions of DEC Unix unless you add +<code>-save-temps</code> to <code>CFLAGS</code>. On these systems, the name of the +assembler input file is stored in the object file, and that makes +comparison fail if it differs between the <code>stage1</code> and +<code>stage2</code> compilations. The option <code>-save-temps</code> forces a +fixed name to be used for the assembler input file, instead of a +randomly chosen name in <code>/tmp</code>. Do not add <code>-save-temps</code> +unless the comparisons fail without that option. If you add +<code>-save-temps</code>, you will have to manually delete the <code>.i</code> and +<code>.s</code> files after each series of compilations. + +<p>GCC now supports both the native (ECOFF) debugging format used by DBX +and GDB and an encapsulated STABS format for use only with GDB. See the +discussion of the <code>--with-stabs</code> option of <code>configure</code> above +for more information on these formats and how to select them. + +<p>There is a bug in DEC's assembler that produces incorrect line numbers +for ECOFF format when the <code>.align</code> directive is used. To work +around this problem, GCC will not emit such alignment directives +while writing ECOFF format debugging information even if optimization is +being performed. Unfortunately, this has the very undesirable +side-effect that code addresses when <code>-O</code> is specified are +different depending on whether or not <code>-g</code> is also specified. + +<p>To avoid this behavior, specify <code>-gstabs+</code> and use GDB instead of +DBX. DEC is now aware of this problem with the assembler and hopes to +provide a fix shortly. + +<hr /> + +<h3><a name="TOC2"></a><a name="alphaev5-cray-unicosmk*"></a>alphaev5-cray-unicosmk*</h3> + +<p>Cray T3E systems running Unicos/Mk. + +<p>This port is incomplete and has many known bugs. We hope to improve the +support for this target soon. Currently, only the C front end is supported, +and it is not possible to build parallel applications. Cray modules are not +supported; in particular, Craylibs are assumed to be in +<code>/opt/ctl/craylibs/craylibs</code>. + +<p>You absolutely <strong>must</strong> use GNU make on this platform. Also, you +need to tell GCC where to find the assembler and the linker. The +simplest way to do so is by providing <code>--with-as</code> and +<code>--with-ld</code> to <code>configure</code>, e.g. + +<br><pre> configure --with-as=/opt/ctl/bin/cam --with-ld=/opt/ctl/bin/cld \ + --enable-languages=c +</pre> + +<p>The comparison test during <code>make bootstrap</code> fails on Unicos/Mk +because the assembler inserts timestamps into object files. You should +be able to work around this by doing <code>make all</code> after getting this +failure. + +<hr /> + +<h3><a name="TOC3"></a><a name="arc-*-elf"></a>arc-*-elf</h3> + +<p>Argonaut ARC processor. +This configuration is intended for embedded systems. + +<hr /> + +<h3><a name="TOC4"></a><a name="arm-*-aout"></a>arm-*-aout</h3> + +<p>This configuration is obsoleted in GCC 3.3. + +<p>Advanced RISC Machines ARM-family processors. These are often used in +embedded applications. There are no standard Unix configurations. +This configuration corresponds to the basic instruction sequences and will +produce <code>a.out</code> format object modules. + +<p>You may need to make a variant of the file <code>arm.h</code> for your particular +configuration. + +<hr /> + +<h3><a name="TOC5"></a><a name="arm-*-elf"></a>arm-*-elf</h3> + +<p>This configuration is intended for embedded systems. + +<hr /> + +<h3><a name="TOC6"></a><a name="arm*-*-linux-gnu"></a>arm*-*-linux-gnu</h3> + +<p>We require GNU binutils 2.10 or newer. + +<hr /> + +<h3><a name="TOC7"></a><a name="avr"></a>avr</h3> + +<p>ATMEL AVR-family micro controllers. These are used in embedded +applications. There are no standard Unix configurations. +See "AVR Options" in the main manual +for the list of supported MCU types. + +<p>Use <code>configure --target=avr --enable-languages="c"</code> to configure GCC. + +<p>Further installation notes and other useful information about AVR tools +can also be obtained from: + +<ul> +<li><a href="http://www.openavr.org">http://www.openavr.org</a> +<li><a href="http://home.overta.ru/users/denisc/">http://home.overta.ru/users/denisc/</a> +<li><a href="http://www.amelek.gda.pl/avr/">http://www.amelek.gda.pl/avr/</a> +</ul> + +<p>We <em>strongly</em> recommend using binutils 2.13 or newer. + +<p>The following error: +<br><pre> Error: register required +</pre> + +<p>indicates that you should upgrade to a newer version of the binutils. + +<hr /> + +<h3><a name="TOC8"></a><a name="c4x"></a>c4x</h3> + +<p>Texas Instruments TMS320C3x and TMS320C4x Floating Point Digital Signal +Processors. These are used in embedded applications. There are no +standard Unix configurations. +See "TMS320C3x/C4x Options" in the main manual +for the list of supported MCU types. + +<p>GCC can be configured as a cross compiler for both the C3x and C4x +architectures on the same system. Use <code>configure --target=c4x +--enable-languages="c,c++"</code> to configure. + +<p>Further installation notes and other useful information about C4x tools +can also be obtained from: + +<ul> +<li><a href="http://www.elec.canterbury.ac.nz/c4x/">http://www.elec.canterbury.ac.nz/c4x/</a> +</ul> + +<hr /> + +<h3><a name="TOC9"></a><a name="cris"></a>CRIS</h3> + +<p>CRIS is the CPU architecture in Axis Communications ETRAX system-on-a-chip +series. These are used in embedded applications. + +<p>See "CRIS Options" in the main manual +for a list of CRIS-specific options. + +<p>There are a few different CRIS targets: +<dl> +<dt><code>cris-axis-aout</code> +<dd>Old target. Includes a multilib for the <code>elinux</code> a.out-based +target. No multilibs for newer architecture variants. +<br><dt><code>cris-axis-elf</code> +<dd>Mainly for monolithic embedded systems. Includes a multilib for the +<code>v10</code> core used in <code>ETRAX 100 LX</code>. +<br><dt><code>cris-axis-linux-gnu</code> +<dd>A GNU/Linux port for the CRIS architecture, currently targeting +<code>ETRAX 100 LX</code> by default. +</dl> + +<p>For <code>cris-axis-aout</code> and <code>cris-axis-elf</code> you need binutils 2.11 +or newer. For <code>cris-axis-linux-gnu</code> you need binutils 2.12 or newer. + +<p>Pre-packaged tools can be obtained from +<a href="ftp://ftp.axis.com/pub/axis/tools/cris/compiler-kit/">ftp://ftp.axis.com/pub/axis/tools/cris/compiler-kit/</a>. More +information about this platform is available at +<a href="http://developer.axis.com/">http://developer.axis.com/</a>. + +<hr /> + +<h3><a name="TOC10"></a><a name="dos"></a>DOS</h3> + +<p>Please have a look at our <a href="binaries.html">binaries page</a>. + +<p>You cannot install GCC by itself on MSDOS; it will not compile under +any MSDOS compiler except itself. You need to get the complete +compilation package DJGPP, which includes binaries as well as sources, +and includes all the necessary compilation tools and libraries. + +<hr /> + +<h3><a name="TOC11"></a><a name="dsp16xx"></a>dsp16xx</h3> + +<p>A port to the AT&T DSP1610 family of processors. + +<hr /> + +<h3><a name="TOC12"></a><a name="*-*-freebsd*"></a>*-*-freebsd*</h3> + +<p>The version of binutils installed in <code>/usr/bin</code> is known to work unless +otherwise specified in any per-architecture notes. However, binutils +2.12.1 or greater is known to improve overall testsuite results. + +<p>Support for FreeBSD 1 was discontinued in GCC 3.2. + +<p>For FreeBSD 2 or any mutant a.out versions of FreeBSD 3: All +configuration support and files as shipped with GCC 2.95 are still in +place. FreeBSD 2.2.7 has been known to bootstrap completely; however, +it is unknown which version of binutils was used (it is assumed that it +was the system copy in <code>/usr/bin</code>) and C++ EH failures were noted. + +<p>For FreeBSD using the ELF file format: DWARF 2 debugging is now the +default for all CPU architectures. It had been the default on +FreeBSD/alpha since its inception. You may use <code>-gstabs</code> instead +of <code>-g</code>, if you really want the old debugging format. There are +no known issues with mixing object files and libraries with different +debugging formats. Otherwise, this release of GCC should now match more +of the configuration used in the stock FreeBSD configuration of GCC. In +particular, <code>--enable-threads</code> is now configured by default. +However, as a general user, do not attempt to replace the system +compiler with this release. Known to bootstrap and check with good +results on FreeBSD 4.8-STABLE and 5-CURRENT. In the past, known to +bootstrap and check with good results on FreeBSD 3.0, 3.4, 4.0, 4.2, +4.3, 4.4, 4.5-STABLE. + +<p>In principle, <code>--enable-threads</code> is now compatible with +<code>--enable-libgcj</code> on FreeBSD. However, it has only been built +and tested on <code>i386-*-freebsd[45]</code> and <code>alpha-*-freebsd[45]</code>. +The static +library may be incorrectly built (symbols are missing at link time). +There is a rare timing-based startup hang (probably involves an +assumption about the thread library). Multi-threaded boehm-gc (required for +libjava) exposes severe threaded signal-handling bugs on FreeBSD before +4.5-RELEASE. Other CPU architectures +supported by FreeBSD will require additional configuration tuning in, at +the very least, both boehm-gc and libffi. + +<p>Shared <code>libgcc_s.so</code> is now built and installed by default. + +<hr /> + +<h3><a name="TOC13"></a><a name="h8300-hms"></a>h8300-hms</h3> + +<p>Renesas H8/300 series of processors. + +<p>Please have a look at our <a href="binaries.html">binaries page</a>. + +<p>The calling convention and structure layout has changed in release 2.6. +All code must be recompiled. The calling convention now passes the +first three arguments in function calls in registers. Structures are no +longer a multiple of 2 bytes. + +<hr /> + +<h3><a name="TOC14"></a><a name="hppa*-hp-hpux*"></a>hppa*-hp-hpux*</h3> + +<p>Support for HP-UX versions 7, 8, and 9 is obsoleted in GCC 3.3. + +<p>We <em>highly</em> recommend using gas/binutils 2.8 or newer on all hppa +platforms; you may encounter a variety of problems when using the HP +assembler. + +<p>Specifically, <code>-g</code> does not work on HP-UX (since that system +uses a peculiar debugging format which GCC does not know about), unless you +use GAS and GDB and configure GCC with the +<a href="./configure.html#with-gnu-as"><code>--with-gnu-as</code></a> and +<code>--with-as=<small>...</small></code> options. + +<p>If you wish to use the pa-risc 2.0 architecture support with a 32-bit +runtime, you must use either the HP assembler, gas/binutils 2.11 or newer, +or a recent +<a href="ftp://sources.redhat.com/pub/binutils/snapshots">snapshot of gas</a>. + +<p>There are two default scheduling models for instructions. These are +PROCESSOR_7100LC and PROCESSOR_8000. They are selected from the pa-risc +architecture specified for the target machine when configuring. +PROCESSOR_8000 is the default. PROCESSOR_7100LC is selected when +the target is a <code>hppa1*</code> machine. + +<p>The PROCESSOR_8000 model is not well suited to older processors. Thus, +it is important to completely specify the machine architecture when +configuring if you want a model other than PROCESSOR_8000. The macro +TARGET_SCHED_DEFAULT can be defined in BOOT_CFLAGS if a different +default scheduling model is desired. + +<p>More specific information to <code>hppa*-hp-hpux*</code> targets follows. + +<hr /> + +<h3><a name="TOC15"></a><a name="hppa*-hp-hpux9"></a>hppa*-hp-hpux9</h3> + +<p>Support for this system is obsoleted in GCC 3.3. + +<p>The HP assembler has major problems on this platform. We've tried to work +around the worst of the problems. However, those workarounds may be causing +linker crashes in some circumstances; the workarounds also probably prevent +shared libraries from working. Use the GNU assembler to avoid these problems. + +<p>The configuration scripts for GCC will also trigger a bug in the hpux9 +shell. To avoid this problem set <code>CONFIG_SHELL</code> to <code>/bin/ksh</code> +and <code>SHELL</code> to <code>/bin/ksh</code> in your environment. + +<hr /> + +<h3><a name="TOC16"></a><a name="hppa*-hp-hpux10"></a>hppa*-hp-hpux10</h3> + +<p>For hpux10.20, we <em>highly</em> recommend you pick up the latest sed patch +<code>PHCO_19798</code> from HP. HP has two sites which provide patches free of +charge: + +<ul> +<li><a href="http://us.itrc.hp.com/service/home/home.do">US, Canada, Asia-Pacific, and +Latin-America</a> +<li><a href="http://europe.itrc.hp.com/service/home/home.do">http://europe.itrc.hp.com/service/home/home.do</a> Europe. +</ul> + +<p>The HP assembler on these systems is much better than the hpux9 assembler, +but still has some problems. Most notably the assembler inserts timestamps +into each object file it creates, causing the 3-stage comparison test to fail +during a <code>make bootstrap</code>. You should be able to continue by +saying <code>make all</code> after getting the failure from <code>make +bootstrap</code>. + +<hr /> + +<h3><a name="TOC17"></a><a name="hppa*-hp-hpux11"></a>hppa*-hp-hpux11</h3> + +<p>GCC 3.0 and up support HP-UX 11. On 64-bit capable systems, there +are two distinct ports. The <code>hppa2.0w-hp-hpux11*</code> port generates +code for the 32-bit pa-risc runtime architecture. It uses the HP +linker. The <code>hppa64-hp-hpux11*</code> port generates 64-bit code for the +pa-risc 2.0 architecture. The script config.guess now selects the port +type based on the type compiler detected during configuration. You must +set your <code>PATH</code> or define <code>CC</code> so that configure finds an appropriate +compiler for the initial bootstrap. Different prefixes must be used if +both ports are to be installed on the same system. + +<p>It is best to explicitly configure the <code>hppa64-hp-hpux11*</code> target +with the <code>--with-ld=<small>...</small></code> option. We support both the HP +and GNU linkers for this target. The two linkers require different +link commands. Thus, it's not possible to switch linkers during a +GCC build. This has been been reported to occur in a unified build +of binutils and GCC. + +<p>GCC 2.95.x is not supported under HP-UX 11 and cannot be used to +compile GCC 3.0 and up. Refer to <a href="binaries.html">binaries</a> for +information about obtaining precompiled GCC binaries for HP-UX. + +<p>You must use GNU binutils 2.11 or above with the 32-bit port. Thread +support is not currently implemented, so <code>--enable-threads</code> does +not work. See: + +<ul> +<li><a href="http://gcc.gnu.org/ml/gcc-prs/2002-01/msg00551.html">http://gcc.gnu.org/ml/gcc-prs/2002-01/msg00551.html</a> +<li><a href="http://gcc.gnu.org/ml/gcc-bugs/2002-01/msg00663.html">http://gcc.gnu.org/ml/gcc-bugs/2002-01/msg00663.html</a> +</ul> + +<p>GCC 3.3 and later support weak symbols on the 32-bit port using SOM +secondary definition symbols. This feature is not enabled for earlier +versions of HP-UX since there have been bugs in the linker support for +secondary symbols. The HP linker patches <code>PHSS_26559</code> and +<code>PHSS_24304</code> for HP-UX 11.00 and 11.11, respectively, correct the +problem of linker core dumps creating C++ libraries. Earlier patches +may work but they have not been tested. + +<p>GCC 3.3 nows uses the ELF DT_INIT_ARRAY and DT_FINI_ARRAY capability +to run initializers and finalizers on the 64-bit port. The feature +requires CVS binutils as of January 2, 2003, or a subsequent release +to correct a problem arising from HP's non-standard use of the .init +and .fini sections. The 32-bit port uses the linker <code>+init</code> +and <code>+fini</code> options. As with the support for secondary symbols, +there have been bugs in the order in which these options are executed +by the HP linker. So, again a recent linker patch is recommended. + +<p>The HP assembler has many limitations and is not recommended for either +the 32 or 64-bit ports. For example, it does not support weak symbols +or alias definitions. As a result, explicit template instantiations +are required when using C++. This will make it difficult if not +impossible to build many C++ applications. You also can't generate +debugging information when using the HP assembler with GCC. + +<p>There are a number of issues to consider in selecting which linker to +use with the 64-bit port. The GNU 64-bit linker can only create dynamic +binaries. The <code>-static</code> option causes linking with archive +libraries but doesn't produce a truly static binary. Dynamic binaries +still require final binding by the dynamic loader to resolve a set of +dynamic-loader-defined symbols. The default behavior of the HP linker +is the same as the GNU linker. However, it can generate true 64-bit +static binaries using the <code>+compat</code> option. + +<p>The HP 64-bit linker doesn't support linkonce semantics. As a +result, C++ programs have many more sections than they should. + +<p>The GNU 64-bit linker has some issues with shared library support +and exceptions. As a result, we only support libgcc in archive +format. For similar reasons, dwarf2 unwind and exception support +are disabled. The GNU linker also has problems creating binaries +with <code>-static</code>. It doesn't provide stubs for internal +calls to global functions in shared libraries, so these calls +can't be overloaded. + +<p>There are several possible approaches to building the distribution. +Binutils can be built first using the HP tools. Then, the GCC +distribution can be built. The second approach is to build GCC +first using the HP tools, then build binutils, then rebuild GCC. +There have been problems with various binary distributions, so +it is best not to start from a binary distribution. + +<p>When starting with a HP compiler, it is preferable to use the ANSI +compiler as the bundled compiler only supports traditional C. +Bootstrapping with the bundled compiler is tested infrequently and +problems often arise because of the subtle differences in semantics +between traditional and ISO C. + +<p>This port still is undergoing significant development. + +<hr /> + +<h3><a name="TOC18"></a><a name="i370-*-*"></a>i370-*-*</h3> + +<p>This port is very preliminary and has many known bugs. We hope to +have a higher-quality port for this machine soon. + +<hr /> + +<h3><a name="TOC19"></a><a name="*-*-linux-gnu"></a>*-*-linux-gnu</h3> + +<p>Versions of libstdc++-v3 starting with 3.2.1 require bugfixes present +in glibc 2.2.5 and later. More information is available in the +libstdc++-v3 documentation. + +<p>If you use glibc 2.2 (or 2.1.9x), GCC 2.95.2 won't install +out-of-the-box. You'll get compile errors while building <code>libstdc++</code>. +The patch <a href="glibc-2.2.patch">glibc-2.2.patch</a>, that is to be +applied in the GCC source tree, fixes the compatibility problems. + +<p>Currently Glibc 2.2.3 (and older releases) and GCC 3.0 are out of sync +since the latest exception handling changes for GCC. Compiling glibc +with GCC 3.0 will give a binary incompatible glibc and therefore cause +lots of problems and might make your system completely unusable. This +will definitely need fixes in glibc but might also need fixes in GCC. We +strongly advise to wait for glibc 2.2.4 and to read the release notes of +glibc 2.2.4 whether patches for GCC 3.0 are needed. You can use glibc +2.2.3 with GCC 3.0, just do not try to recompile it. + +<hr /> + +<h3><a name="TOC20"></a><a name="ix86-*-linux*aout"></a>i?86-*-linux*aout</h3> + +<p>Use this configuration to generate <code>a.out</code> binaries on Linux-based +GNU systems. This configuration is being superseded. You must use +gas/binutils version 2.5.2 or later. + +<hr /> + +<h3><a name="TOC21"></a><a name="ix86-*-linux*"></a>i?86-*-linux*</h3> + +<p>As of GCC 3.3, binutils 2.13.1 or later is required for this platform. +See <a href="http://gcc.gnu.org/PR10877">bug 10877</a> for more information. + +<p>If you receive Signal 11 errors when building on GNU/Linux, then it is +possible you have a hardware problem. Further information on this can be +found on <a href="http://www.bitwizard.nl/sig11/">www.bitwizard.nl</a>. + +<hr /> + +<h3><a name="TOC22"></a><a name="ix86-*-sco"></a>i?86-*-sco</h3> + +<p>Compilation with RCC is recommended. Also, it may be a good idea to +link with GNU malloc instead of the malloc that comes with the system. + +<hr /> + +<h3><a name="TOC23"></a><a name="ix86-*-sco3.2v5*"></a>i?86-*-sco3.2v5*</h3> + +<p>Use this for the SCO OpenServer Release 5 family of operating systems. + +<p>Unlike earlier versions of GCC, the ability to generate COFF with this +target is no longer provided. + +<p>Earlier versions of GCC emitted DWARF 1 when generating ELF to allow +the system debugger to be used. That support was too burdensome to +maintain. GCC now emits only DWARF 2 for this target. This means you +may use either the UDK debugger or GDB to debug programs built by this +version of GCC. + +<p>GCC is now only supported on releases 5.0.4 and later, and requires that +you install Support Level Supplement OSS646B or later, and the latest +version of the Supplement Graphics, Web and X11 Libraries (GWXLIBS) +package. If you are using release 5.0.7 of OpenServer, you must have at +least the first maintenance pack installed (this includes the relevant +portions of OSS646 and GWXLIBS). OSS646, also known as the "Execution +Environment Update", provides updated link editors and assemblers, as well +as updated standard C and math libraries. The C startup modules are also +updated to support the System V gABI draft, and GCC relies on that +behavior. GWXLIBS provides a collection of commonly used open source +libraries, some of which GCC depends on (such as GNU gettext and zlib). +SCO OpenServer Release 5.0.7 has all of this built in by default, but +GWXLIBS is significantly updated in Maintenance Pack 1. Please visit +<a href="ftp://ftp.sco.com/pub/openserver5">ftp://ftp.sco.com/pub/openserver5</a> +and +<a href="ftp://ftp.sco.com/pub/openserver5/opensrc">ftp://ftp.sco.com/pub/openserver5/opensrc</a> +for the latest versions of these (and other potentially useful) supplements. + +<p>Although there is support for using the native assembler, it is recommended +that you configure GCC to use the GNU assembler. You do this by using the +flags <a href="./configure.html#with-gnu-as"><code>--with-gnu-as</code></a>. You +should use a modern version of GNU binutils. Version 2.14 was used for all +testing. In general, only the <code>--with-gnu-as</code> option is tested. A +modern bintuils (as well as a plethora of other development related GNU +utilities) can be found in the GNU Development Tools package. See the +SCO web and ftp sites for details. That package also contains the +currently "officially supported" version of GCC, version 2.95.3. It is +useful for bootstrapping this version. + +<hr /> + +<h3><a name="TOC24"></a><a name="ix86-*-udk"></a>i?86-*-udk</h3> + +<p>This target emulates the SCO Universal Development Kit and requires that +package be installed. (If it is installed, you will have a +<code>/udk/usr/ccs/bin/cc</code> file present.) It's very much like the +<code>i?86-*-unixware7*</code> target +but is meant to be used when hosting on a system where UDK isn't the +default compiler such as OpenServer 5 or Unixware 2. This target will +generate binaries that will run on OpenServer, Unixware 2, or Unixware 7, +with the same warnings and caveats as the SCO UDK. + +<p>This target is a little tricky to build because we have to distinguish +it from the native tools (so it gets headers, startups, and libraries +from the right place) while making the tools not think we're actually +building a cross compiler. The easiest way to do this is with a configure +command like this: + +<br><pre> CC=/udk/usr/ccs/bin/cc <var>/your/path/to</var>/gcc/configure \ + --host=i686-pc-udk --target=i686-pc-udk --program-prefix=udk- +</pre> + +<p><em>You should substitute <code>i686</code> in the above command with the appropriate +processor for your host.</em> + +<p>After the usual <code>make bootstrap</code> and +<code>make install</code>, you can then access the UDK-targeted GCC +tools by adding <code>udk-</code> before the commonly known name. For +example, to invoke the C compiler, you would use <code>udk-gcc</code>. +They will coexist peacefully with any native-target GCC tools you may +have installed. + +<hr /> + +<h3><a name="TOC25"></a><a name="ia64-*-linux"></a>ia64-*-linux</h3> + +<p>IA-64 processor (also known as IPF, or Itanium Processor Family) +running GNU/Linux. + +<p>The toolchain is not completely finished, so requirements will continue +to change. +GCC 3.0.1 and later require glibc 2.2.4. +GCC 3.0.2 requires binutils from 2001-09-05 or later. +GCC 3.0.1 requires binutils 2.11.1 or later. + +<p>None of the following versions of GCC has an ABI that is compatible +with any of the other versions in this list, with the exception that +Red Hat 2.96 and Trillian 000171 are compatible with each other: +3.0.2, 3.0.1, 3.0, Red Hat 2.96, and Trillian 000717. +This primarily affects C++ programs and programs that create shared libraries. +Because of these ABI incompatibilities, GCC 3.0.2 is not recommended for +user programs on GNU/Linux systems built using earlier compiler releases. +GCC 3.0.2 is recommended for compiling linux, the kernel. +GCC 3.0.2 is believed to be fully ABI compliant, and hence no more major +ABI changes are expected. + +<hr /> + +<h3><a name="TOC26"></a><a name="ia64-*-hpux*"></a>ia64-*-hpux*</h3> + +<p>Building GCC on this target requires the GNU Assembler. The bundled HP +assembler will not work. To prevent GCC from using the wrong assembler, +the option <code>--with-gnu-as</code> may be necessary. + +<p>The GCC libunwind library has not been ported to HPUX. This means that for +GCC versions 3.2.3 and earlier, <code>--enable-libunwind-exceptions</code> +is required to build GCC. For GCC 3.3 and later, this is the default. + +<hr /> + +<h3><a name="TOC27"></a><a name="*-lynx-lynxos"></a>*-lynx-lynxos</h3> + +<p>Support for SPARC LynxOS is obsoleted in GCC 3.3. + +<p>LynxOS 2.2 and earlier comes with GCC 1.x already installed as +<code>/bin/gcc</code>. You should compile with this instead of <code>/bin/cc</code>. +You can tell GCC to use the GNU assembler and linker, by specifying +<code>--with-gnu-as --with-gnu-ld</code> when configuring. These will produce +COFF format object files and executables; otherwise GCC will use the +installed tools, which produce <code>a.out</code> format executables. + +<hr /> +<!- rs6000-ibm-aix*, powerpc-ibm-aix* -> + +<h3><a name="TOC28"></a><a name="*-ibm-aix*"></a>*-ibm-aix*</h3> + +<p>Support for AIX versions 1, 2, and 3 is obsoleted in GCC 3.3. + +<p>AIX Make frequently has problems with GCC makefiles. GNU Make 3.76 or +newer is recommended to build on this platform. + +<p>Errors involving <code>alloca</code> when building GCC generally are due +to an incorrect definition of <code>CC</code> in the Makefile or mixing files +compiled with the native C compiler and GCC. During the stage1 phase of +the build, the native AIX compiler <strong>must</strong> be invoked as <code>cc</code> +(not <code>xlc</code>). Once <code>configure</code> has been informed of +<code>xlc</code>, one needs to use <code>make distclean</code> to remove the +configure cache files and ensure that <code>CC</code> environment variable +does not provide a definition that will confuse <code>configure</code>. +If this error occurs during stage2 or later, then the problem most likely +is the version of Make (see above). + +<p>The native <code>as</code> and <code>ld</code> are recommended for bootstrapping +on AIX 4 and required for bootstrapping on AIX 5L. The GNU Assembler +reports that it supports WEAK symbols on AIX 4, which causes GCC to try to +utilize weak symbol functionality although it is not supported. The GNU +Assembler and Linker do not support AIX 5L sufficiently to bootstrap GCC. +The native AIX tools do interoperate with GCC. + +<p>Building <code>libstdc++.a</code> requires a fix for an AIX Assembler bug +APAR IY26685 (AIX 4.3) or APAR IY25528 (AIX 5.1). + +<p><code>libstdc++</code> in GCC 3.2 increments the major version number of the +shared object and GCC installation places the <code>libstdc++.a</code> +shared library in a common location which will overwrite the GCC 3.1 +version of the shared library. Applications either need to be +re-linked against the new shared library or the GCC 3.1 version of the +<code>libstdc++</code> shared object needs to be available to the AIX +runtime loader. The GCC 3.1 <code>libstdc++.so.4</code> shared object can +be installed for runtime dynamic loading using the following steps to +set the <code>F_LOADONLY</code> flag in the shared object for <em>each</em> +multilib <code>libstdc++.a</code> installed: + +<p>Extract the shared object from each the GCC 3.1 <code>libstdc++.a</code> +archive: +<br><pre> % ar -x libstdc++.a libstdc++.so.4 +</pre> + +<p>Enable the <code>F_LOADONLY</code> flag so that the shared object will be +available for runtime dynamic loading, but not linking: +<br><pre> % strip -e libstdc++.so.4 +</pre> + +<p>Archive the runtime-only shared object in the GCC 3.2 +<code>libstdc++.a</code> archive: +<br><pre> % ar -q libstdc++.a libstdc++.so.4 +</pre> + +<p>Linking executables and shared libraries may produce warnings of +duplicate symbols. The assembly files generated by GCC for AIX always +have included multiple symbol definitions for certain global variable +and function declarations in the original program. The warnings should +not prevent the linker from producing a correct library or runnable +executable. + +<p>AIX 4.3 utilizes a "large format" archive to support both 32-bit and +64-bit object modules. The routines provided in AIX 4.3.0 and AIX 4.3.1 +to parse archive libraries did not handle the new format correctly. +These routines are used by GCC and result in error messages during +linking such as "not a COFF file". The version of the routines shipped +with AIX 4.3.1 should work for a 32-bit environment. The <code>-g</code> +option of the archive command may be used to create archives of 32-bit +objects using the original "small format". A correct version of the +routines is shipped with AIX 4.3.2 and above. + +<p>Some versions of the AIX binder (linker) can fail with a relocation +overflow severe error when the <code>-bbigtoc</code> option is used to link +GCC-produced object files into an executable that overflows the TOC. A fix +for APAR IX75823 (OVERFLOW DURING LINK WHEN USING GCC AND -BBIGTOC) is +available from IBM Customer Support and from its +<a href="http://techsupport.services.ibm.com/">techsupport.services.ibm.com</a> +website as PTF U455193. + +<p>The AIX 4.3.2.1 linker (bos.rte.bind_cmds Level 4.3.2.1) will dump core +with a segmentation fault when invoked by any version of GCC. A fix for +APAR IX87327 is available from IBM Customer Support and from its +<a href="http://techsupport.services.ibm.com/">techsupport.services.ibm.com</a> +website as PTF U461879. This fix is incorporated in AIX 4.3.3 and above. + +<p>The initial assembler shipped with AIX 4.3.0 generates incorrect object +files. A fix for APAR IX74254 (64BIT DISASSEMBLED OUTPUT FROM COMPILER FAILS +TO ASSEMBLE/BIND) is available from IBM Customer Support and from its +<a href="http://techsupport.services.ibm.com/">techsupport.services.ibm.com</a> +website as PTF U453956. This fix is incorporated in AIX 4.3.1 and above. + +<p>AIX provides National Language Support (NLS). Compilers and assemblers +use NLS to support locale-specific representations of various data +formats including floating-point numbers (e.g., <code>.</code> vs <code>,</code> for +separating decimal fractions). There have been problems reported where +GCC does not produce the same floating-point formats that the assembler +expects. If one encounters this problem, set the <code>LANG</code> +environment variable to <code>C</code> or <code>En_US</code>. + +<p>By default, GCC for AIX 4.1 and above produces code that can be used on +both Power or PowerPC processors. + +<p>A default can be specified with the <code>-mcpu=<var>cpu_type</var></code> +switch and using the configure option <code>--with-cpu-<var>cpu_type</var></code>. + +<hr /> + +<h3><a name="TOC29"></a><a name="ip2k-*-elf"></a>ip2k-*-elf</h3> + +<p>Ubicom IP2022 micro controller. +This configuration is intended for embedded systems. +There are no standard Unix configurations. + +<p>Use <code>configure --target=ip2k-elf --enable-languages=c</code> to configure GCC. + +<hr /> + +<h3><a name="TOC30"></a><a name="m32r-*-elf"></a>m32r-*-elf</h3> + +<p>Renesas M32R processor. +This configuration is intended for embedded systems. + +<hr /> + +<h3><a name="TOC31"></a><a name="m68000-hp-bsd"></a>m68000-hp-bsd</h3> + +<p>Support for this system is obsoleted in GCC 3.3. + +<p>HP 9000 series 200 running BSD. Note that the C compiler that comes +with this system cannot compile GCC; contact <a href="mailto:law@cygnus.com">law@cygnus.com</a> +to get binaries of GCC for bootstrapping. + +<hr /> + +<h3><a name="TOC32"></a><a name="m6811-elf"></a>m6811-elf</h3> + +<p>Motorola 68HC11 family micro controllers. These are used in embedded +applications. There are no standard Unix configurations. + +<hr /> + +<h3><a name="TOC33"></a><a name="m6812-elf"></a>m6812-elf</h3> + +<p>Motorola 68HC12 family micro controllers. These are used in embedded +applications. There are no standard Unix configurations. + +<hr /> + +<h3><a name="TOC34"></a><a name="m68k-att-sysv"></a>m68k-att-sysv</h3> + +<p>Support for this system is obsoleted in GCC 3.3. + +<p>AT&T 3b1, a.k.a. 7300 PC. This version of GCC cannot +be compiled with the system C compiler, which is too buggy. +You will need to get a previous version of GCC and use it to +bootstrap. Binaries are available from the OSU-CIS archive, at +<a href="ftp://ftp.uu.net/systems/att7300/">ftp://ftp.uu.net/systems/att7300/</a>. + +<hr /> + +<h3><a name="TOC35"></a><a name="m68k-crds-unos"></a>m68k-crds-unos</h3> + +<p>Support for this system is obsoleted in GCC 3.3. + +<p>Use <code>configure unos</code> for building on Unos. + +<p>The Unos assembler is named <code>casm</code> instead of <code>as</code>. For some +strange reason linking <code>/bin/as</code> to <code>/bin/casm</code> changes the +behavior, and does not work. So, when installing GCC, you should +install the following script as <code>as</code> in the subdirectory where +the passes of GCC are installed: + +<br><pre>#!/bin/sh +casm $* +</pre> + +<p>The default Unos library is named <code>libunos.a</code> instead of +<code>libc.a</code>. To allow GCC to function, either change all +references to <code>-lc</code> in <code>gcc.c</code> to <code>-lunos</code> or link +<code>/lib/libc.a</code> to <code>/lib/libunos.a</code>. + +<p>When compiling GCC with the standard compiler, to overcome bugs in +the support of <code>alloca</code>, do not use <code>-O</code> when making stage 2. +Then use the stage 2 compiler with <code>-O</code> to make the stage 3 +compiler. This compiler will have the same characteristics as the usual +stage 2 compiler on other systems. Use it to make a stage 4 compiler +and compare that with stage 3 to verify proper compilation. + +<p>(Perhaps simply defining <code>ALLOCA</code> in <code>x-crds</code> as described in +the comments there will make the above paragraph superfluous. Please +inform us of whether this works.) + +<p>Unos uses memory segmentation instead of demand paging, so you will need +a lot of memory. 5 Mb is barely enough if no other tasks are running. +If linking <code>cc1</code> fails, try putting the object files into a library +and linking from that library. + +<hr /> + +<h3><a name="TOC36"></a><a name="m68k-hp-hpux"></a>m68k-hp-hpux</h3> + +<p>HP 9000 series 300 or 400 running HP-UX. HP-UX version 8.0 has a bug in +the assembler that prevents compilation of GCC. This +bug manifests itself during the first stage of compilation, while +building <code>libgcc2.a</code>: + +<br><pre>_floatdisf +cc1: warning: `-g' option not supported on this version of GCC +cc1: warning: `-g1' option not supported on this version of GCC +./xgcc: Internal compiler error: program as got fatal signal 11 +</pre> + +<p>A patched version of the assembler is available as the file +<a href="ftp://altdorf.ai.mit.edu/archive/cph/hpux-8.0-assembler">ftp://altdorf.ai.mit.edu/archive/cph/hpux-8.0-assembler</a>. If you +have HP software support, the patch can also be obtained directly from +HP, as described in the following note: + +<blockquote> +This is the patched assembler, to patch SR#1653-010439, where the +assembler aborts on floating point constants. + +<p>The bug is not really in the assembler, but in the shared library +version of the function "cvtnum(3c)". The bug on "cvtnum(3c)" is +SR#4701-078451. Anyway, the attached assembler uses the archive +library version of "cvtnum(3c)" and thus does not exhibit the bug. +</blockquote> + +<p>This patch is also known as PHCO_4484. + +<p>In addition, if you wish to use gas, you must use +gas version 2.1 or later, and you must use the GNU linker version 2.1 or +later. Earlier versions of gas relied upon a program which converted the +gas output into the native HP-UX format, but that program has not been +kept up to date. gdb does not understand that native HP-UX format, so +you must use gas if you wish to use gdb. + +<p>On HP-UX version 8.05, but not on 8.07 or more recent versions, the +<code>fixproto</code> shell script triggers a bug in the system shell. If you +encounter this problem, upgrade your operating system or use BASH (the +GNU shell) to run <code>fixproto</code>. This bug will cause the fixproto +program to report an error of the form: + +<br><pre>./fixproto: sh internal 1K buffer overflow +</pre> + +<p>To fix this, you can also change the first line of the fixproto script +to look like: + +<br><pre>#!/bin/ksh +</pre> + +<hr /> + +<h3><a name="TOC37"></a><a name="m68k-ncr-*"></a>m68k-ncr-*</h3> + +<p>Support for this system is obsoleted in GCC 3.3. + +<p>On the Tower models 4<var>n</var>0 and 6<var>n</var>0, by default a process is not +allowed to have more than one megabyte of memory. GCC cannot compile +itself (or many other programs) with <code>-O</code> in that much memory. + +<p>To solve this problem, reconfigure the kernel adding the following line +to the configuration file: + +<br><pre>MAXUMEM = 4096 +</pre> + +<hr /> + +<h3><a name="TOC38"></a><a name="m68k-sun"></a>m68k-sun</h3> + +<p>Support for this system is obsoleted in GCC 3.3. + +<p>Sun 3. We do not provide a configuration file to use the Sun FPA by +default, because programs that establish signal handlers for floating +point traps inherently cannot work with the FPA. + +<hr /> + +<h3><a name="TOC39"></a><a name="m68k-sun-sunos4.1.1"></a>m68k-sun-sunos4.1.1</h3> + +<p>Support for this system is obsoleted in GCC 3.3. + +<p>It is reported that you may need the GNU assembler on this platform. + +<hr /> + +<h3><a name="TOC40"></a><a name="mips-*-*"></a>mips-*-*</h3> + +<p>If on a MIPS system you get an error message saying "does not have gp +sections for all it's [sic] sectons [sic]", don't worry about it. This +happens whenever you use GAS with the MIPS linker, but there is not +really anything wrong, and it is okay to use the output file. You can +stop such warnings by installing the GNU linker. + +<p>It would be nice to extend GAS to produce the gp tables, but they are +optional, and there should not be a warning about their absence. + +<p>The libstdc++ atomic locking routines for MIPS targets requires MIPS II +and later. A patch went in just after the GCC 3.3 release to +make <code>mips*-*-*</code> use the generic implementation instead. You can also +configure for <code>mipsel-elf</code> as a workaround. The +<code>mips*-*-linux*</code> target continues to use the MIPS II routines. More +work on this is expected in future releases. + +<hr /> + +<h3><a name="TOC41"></a><a name="mips-sgi-irix5"></a>mips-sgi-irix5</h3> + +<p>This configuration has considerable problems, which will be fixed in a +future release. + +<p>In order to compile GCC on an SGI running IRIX 5, the "compiler_dev.hdr" +subsystem must be installed from the IDO CD-ROM supplied by Silicon +Graphics. It is also available for download from +<a href="http://www.sgi.com/developers/devtools/apis/ido.html">http://www.sgi.com/developers/devtools/apis/ido.html</a>. + +<p><code>make compare</code> may fail on version 5 of IRIX unless you add +<code>-save-temps</code> to <code>CFLAGS</code>. On these systems, the name of the +assembler input file is stored in the object file, and that makes +comparison fail if it differs between the <code>stage1</code> and +<code>stage2</code> compilations. The option <code>-save-temps</code> forces a +fixed name to be used for the assembler input file, instead of a +randomly chosen name in <code>/tmp</code>. Do not add <code>-save-temps</code> +unless the comparisons fail without that option. If you do you +<code>-save-temps</code>, you will have to manually delete the <code>.i</code> and +<code>.s</code> files after each series of compilations. + +<p>If you use the MIPS C compiler to bootstrap, it may be necessary +to increase its table size for switch statements with the +<code>-Wf,-XNg1500</code> option. If you use the <code>-O2</code> +optimization option, you also need to use <code>-Olimit 3000</code>. + +<p>To enable debugging under IRIX 5, you must use GNU <code>as</code> 2.11.2 +or later, +and use the <code>--with-gnu-as</code> configure option when configuring GCC. +GNU <code>as</code> is distributed as part of the binutils package. +When using release 2.11.2, you need to apply a patch +<a href="http://sources.redhat.com/ml/binutils/2001-07/msg00352.html">http://sources.redhat.com/ml/binutils/2001-07/msg00352.html</a> +which will be included in the next release of binutils. + +<p>When building GCC, the build process loops rebuilding <code>cc1</code> over +and over again. This happens on <code>mips-sgi-irix5.2</code>, and possibly +other platforms. It has been reported that this is a known bug in the +<code>make</code> shipped with IRIX 5.2. We recommend you use GNU +<code>make</code> instead of the vendor supplied <code>make</code> program; +however, you may have success with <code>smake</code> on IRIX 5.2 if you do +not have GNU <code>make</code> available. + +<hr /> + +<h3><a name="TOC42"></a><a name="mips-sgi-irix6"></a>mips-sgi-irix6</h3> + +<p>If you are using IRIX <code>cc</code> as your bootstrap compiler, you must +ensure that the N32 ABI is in use. To test this, compile a simple C +file with <code>cc</code> and then run <code>file</code> on the +resulting object file. The output should look like: + +<br><pre>test.o: ELF N32 MSB <small>...</small> +</pre> + +<p>If you see: + +<br><pre>test.o: ELF 32-bit MSB <small>...</small> +</pre> + +<p>or + +<br><pre>test.o: ELF 64-bit MSB <small>...</small> +</pre> + +<p>then your version of <code>cc</code> uses the O32 or N64 ABI by default. You +should set the environment variable <code>CC</code> to <code>cc -n32</code> +before configuring GCC. + +<p>If you want the resulting <code>gcc</code> to run on old 32-bit systems +with the MIPS R4400 CPU, you need to ensure that only code for the mips3 +instruction set architecture (ISA) is generated. While GCC 3.x does +this correctly, both GCC 2.95 and SGI's MIPSpro <code>cc</code> may change +the ISA depending on the machine where GCC is built. Using one of them +as the bootstrap compiler may result in mips4 code, which won't run at +all on mips3-only systems. For the test program above, you should see: + +<br><pre>test.o: ELF N32 MSB mips-3 <small>...</small> +</pre> + +<p>If you get: + +<br><pre>test.o: ELF N32 MSB mips-4 <small>...</small> +</pre> + +<p>instead, you should set the environment variable <code>CC</code> to <code>cc +-n32 -mips3</code> or <code>gcc -mips3</code> respectively before configuring GCC. + +<p>GCC on IRIX 6 is usually built to support both the N32 and N64 ABIs. If +you build GCC on a system that doesn't have the N64 libraries installed, +you need to configure with <code>--disable-multilib</code> so GCC doesn't +try to use them. Look for <code>/usr/lib64/libc.so.1</code> to see if you +have the 64-bit libraries installed. + +<p>You must <em>not</em> use GNU <code>as</code> (which isn't built anyway as of +binutils 2.11.2) on IRIX 6 platforms; doing so will only cause problems. + +<p>GCC does not currently support generating O32 ABI binaries in the +<code>mips-sgi-irix6</code> configurations. It is possible to create a GCC +with O32 ABI only support by configuring it for the <code>mips-sgi-irix5</code> +target and using a patched GNU <code>as</code> 2.11.2 as documented in the +<a href="#mips-sgi-irix5"><code>mips-sgi-irix5</code></a> section above. Using the +native assembler requires patches to GCC which will be included in a +future release. It is +expected that O32 ABI support will be available again in a future release. + +<p>The <code>--enable-threads</code> option doesn't currently work, a patch is +in preparation for a future release. The <code>--enable-libgcj</code> +option is disabled by default: IRIX 6 uses a very low default limit +(20480) for the command line length. Although libtool contains a +workaround for this problem, at least the N64 <code>libgcj</code> is known not +to build despite this, running into an internal error of the native +<code>ld</code>. A sure fix is to increase this limit (<code>ncargs</code>) to +its maximum of 262144 bytes. If you have root access, you can use the +<code>systune</code> command to do this. + +<p>GCC does not correctly pass/return structures which are +smaller than 16 bytes and which are not 8 bytes. The problem is very +involved and difficult to fix. It affects a number of other targets also, +but IRIX 6 is affected the most, because it is a 64-bit target, and 4 byte +structures are common. The exact problem is that structures are being padded +at the wrong end, e.g. a 4 byte structure is loaded into the lower 4 bytes +of the register when it should be loaded into the upper 4 bytes of the +register. + +<p>GCC is consistent with itself, but not consistent with the SGI C compiler +(and the SGI supplied runtime libraries), so the only failures that can +happen are when there are library functions that take/return such +structures. There are very few such library functions. Currently this +is known to affect <code>inet_ntoa</code>, <code>inet_lnaof</code>, +<code>inet_netof</code>, <code>inet_makeaddr</code>, and <code>semctl</code>. Until the +bug is fixed, GCC contains workarounds for the known affected functions. + +<p>See <a href="http://freeware.sgi.com/">http://freeware.sgi.com/</a> for more +information about using GCC on IRIX platforms. + +<hr /> + +<h3><a name="TOC43"></a><a name="powerpc*-*-*"></a>powerpc-*-*</h3> + +<p>You can specify a default version for the <code>-mcpu=<var>cpu_type</var></code> +switch by using the configure option <code>--with-cpu-<var>cpu_type</var></code>. + +<hr /> + +<h3><a name="TOC44"></a><a name="powerpc-*-darwin*"></a>powerpc-*-darwin*</h3> + +<p>PowerPC running Darwin (Mac OS X kernel). + +<p>Pre-installed versions of Mac OS X may not include any developer tools, +meaning that you will not be able to build GCC from source. Tool +binaries are available at +<a href="http://developer.apple.com/tools/compilers.html">http://developer.apple.com/tools/compilers.html</a> (free +registration required). + +<p>The default stack limit of 512K is too small, which may cause compiles +to fail with 'Bus error'. Set the stack larger, for instance +by doing <code>limit stack 800</code>. It's a good idea to use the GNU +preprocessor instead of Apple's <code>cpp-precomp</code> during the first stage of +bootstrapping; this is automatic when doing <code>make bootstrap</code>, but +to do it from the toplevel objdir you will need to say <code>make +CC='cc -no-cpp-precomp' bootstrap</code>. + +<p>The version of GCC shipped by Apple typically includes a number of +extensions not available in a standard GCC release. These extensions +are generally specific to Mac programming. + +<hr /> + +<h3><a name="TOC45"></a><a name="powerpc-*-elf"></a>powerpc-*-elf, powerpc-*-sysv4</h3> + +<p>PowerPC system in big endian mode, running System V.4. + +<hr /> + +<h3><a name="TOC46"></a><a name="powerpc-*-linux-gnu*"></a>powerpc-*-linux-gnu*</h3> + +<p>You will need +<a href="ftp://ftp.kernel.org/pub/linux/devel/binutils">binutils 2.13.90.0.10</a> +or newer for a working GCC. + +<hr /> + +<h3><a name="TOC47"></a><a name="powerpc-*-netbsd*"></a>powerpc-*-netbsd*</h3> + +<p>PowerPC system in big endian mode running NetBSD. To build the +documentation you will need Texinfo version 4.2 (NetBSD 1.5.1 included +Texinfo version 3.12). + +<hr /> + +<h3><a name="TOC48"></a><a name="powerpc-*-eabiaix"></a>powerpc-*-eabiaix</h3> + +<p>Embedded PowerPC system in big endian mode with <code>-mcall-aix</code> selected as +the default. + +<hr /> + +<h3><a name="TOC49"></a><a name="powerpc-*-eabisim"></a>powerpc-*-eabisim</h3> + +<p>Embedded PowerPC system in big endian mode for use in running under the +PSIM simulator. + +<hr /> + +<h3><a name="TOC50"></a><a name="powerpc-*-eabi"></a>powerpc-*-eabi</h3> + +<p>Embedded PowerPC system in big endian mode. + +<hr /> + +<h3><a name="TOC51"></a><a name="powerpcle-*-elf"></a>powerpcle-*-elf, powerpcle-*-sysv4</h3> + +<p>PowerPC system in little endian mode, running System V.4. + +<hr /> + +<h3><a name="TOC52"></a><a name="powerpcle-*-eabisim"></a>powerpcle-*-eabisim</h3> + +<p>Embedded PowerPC system in little endian mode for use in running under +the PSIM simulator. + +<hr /> + +<h3><a name="TOC53"></a><a name="powerpcle-*-eabi"></a>powerpcle-*-eabi</h3> + +<p>Embedded PowerPC system in little endian mode. + +<hr /> + +<h3><a name="TOC54"></a><a name="s390-*-linux*"></a>s390-*-linux*</h3> + +<p>S/390 system running Linux for S/390. + +<hr /> + +<h3><a name="TOC55"></a><a name="s390x-*-linux*"></a>s390x-*-linux*</h3> + +<p>zSeries system (64-bit) running Linux for zSeries. + +<hr /> + +<h3><a name="TOC56"></a><a name="*-*-solaris2*"></a>*-*-solaris2*</h3> + +<p>Sun does not ship a C compiler with Solaris 2. To bootstrap and install +GCC you first have to install a pre-built compiler, see our +<a href="binaries.html">binaries page</a> for details. + +<p>The Solaris 2 <code>/bin/sh</code> will often fail to configure +<code>libstdc++-v3</code>, <code>boehm-gc</code> or <code>libjava</code>. We therefore +recommend to use the following sequence of commands to bootstrap and +install GCC: + +<br><pre> % CONFIG_SHELL=/bin/ksh + % export CONFIG_SHELL + % <var>srcdir</var>/configure [<var>options</var>] [<var>target</var>] + % gmake bootstrap + % gmake install +</pre> + +<p>As explained in the <a href="build.html">build</a> instructions, we recommend +to use GNU make, which we call <code>gmake</code> here to distinguish it +from Sun make. + +<p>Solaris 2 comes with a number of optional OS packages. Some of these +are needed to use GCC fully, namely <code>SUNWarc</code>, +<code>SUNWbtool</code>, <code>SUNWesu</code>, <code>SUNWhea</code>, <code>SUNWlibm</code>, +<code>SUNWsprot</code>, and <code>SUNWtoo</code>. If you did not install all +optional packages when installing Solaris 2, you will need to verify that +the packages that GCC needs are installed. + +<p>To check whether an optional package is installed, use +the <code>pkginfo</code> command. To add an optional package, use the +<code>pkgadd</code> command. For further details, see the Solaris 2 +documentation. + +<p>Trying to use the linker and other tools in +<code>/usr/ucb</code> to install GCC has been observed to cause trouble. +For example, the linker may hang indefinitely. The fix is to remove +<code>/usr/ucb</code> from your <code>PATH</code>. + +<p>The build process works more smoothly with the legacy Sun tools so, if you +have <code>/usr/xpg4/bin</code> in your <code>PATH</code>, we recommend that you place +<code>/usr/bin</code> before <code>/usr/xpg4/bin</code> for the duration of the build. + +<p>All releases of GNU binutils prior to 2.11.2 have known bugs on this +platform. We recommend the use of GNU binutils 2.11.2 or the vendor +tools (Sun <code>as</code>, Sun <code>ld</code>). + +<p>Sun bug 4296832 turns up when compiling X11 headers with GCC 2.95 or +newer: <code>g++</code> will complain that types are missing. These headers assume +that omitting the type means <code>int</code>; this assumption worked for C89 but +is wrong for C++, and is now wrong for C99 also. + +<p><code>g++</code> accepts such (invalid) constructs with the option +<code>-fpermissive</code>; it +will assume that any missing type is <code>int</code> (as defined by C89). + +<p>There are patches for Solaris 2.6 (105633-56 or newer for SPARC, +106248-42 or newer for Intel), Solaris 7 (108376-21 or newer for SPARC, +108377-20 for Intel), and Solaris 8 (108652-24 or newer for SPARC, +108653-22 for Intel) that fix this bug. + +<hr /> + +<h3><a name="TOC57"></a><a name="sparc-sun-solaris2*"></a>sparc-sun-solaris2*</h3> + +<p>When GCC is configured to use binutils 2.11.2 or later the binaries +produced are smaller than the ones produced using Sun's native tools; +this difference is quite significant for binaries containing debugging +information. + +<p>Sun <code>as</code> 4.x is broken in that it cannot cope with long symbol names. +A typical error message might look similar to the following: + +<br><pre>/usr/ccs/bin/as: "/var/tmp/ccMsw135.s", line 11041: error: + can't compute value of an expression involving an external symbol. +</pre> + +<p>This is Sun bug 4237974. This is fixed with patch 108908-02 for Solaris +2.6 and has been fixed in later (5.x) versions of the assembler, +starting with Solaris 7. + +<p>Starting with Solaris 7, the operating system is capable of executing +64-bit SPARC V9 binaries. GCC 3.1 and later properly supports +this; the <code>-m64</code> option enables 64-bit code generation. +However, if all you want is code tuned for the UltraSPARC CPU, you +should try the <code>-mtune=ultrasparc</code> option instead, which produces +code that, unlike full 64-bit code, can still run on non-UltraSPARC +machines. + +<p>When configuring on a Solaris 7 or later system that is running a kernel +that supports only 32-bit binaries, one must configure with +<code>--disable-multilib</code>, since we will not be able to build the +64-bit target libraries. + +<hr /> + +<h3><a name="TOC58"></a><a name="sparc-sun-solaris2.7"></a>sparc-sun-solaris2.7</h3> + +<p>Sun patch 107058-01 (1999-01-13) for Solaris 7/SPARC triggers a bug in +the dynamic linker. This problem (Sun bug 4210064) affects GCC 2.8 +and later, including all EGCS releases. Sun formerly recommended +107058-01 for all Solaris 7 users, but around 1999-09-01 it started to +recommend it only for people who use Sun's compilers. + +<p>Here are some workarounds to this problem: +<ul> +<li>Do not install Sun patch 107058-01 until after Sun releases a +complete patch for bug 4210064. This is the simplest course to take, +unless you must also use Sun's C compiler. Unfortunately 107058-01 +is preinstalled on some new Solaris 7-based hosts, so you may have to +back it out. + +<li>Copy the original, unpatched Solaris 7 +<code>/usr/ccs/bin/as</code> into +<code>/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/3.1/as</code>, +adjusting the latter name to fit your local conventions and software +version numbers. + +<li>Install Sun patch 106950-03 (1999-05-25) or later. Nobody with +both 107058-01 and 106950-03 installed has reported the bug with GCC +and Sun's dynamic linker. This last course of action is riskiest, +for two reasons. First, you must install 106950 on all hosts that +run code generated by GCC; it doesn't suffice to install it only on +the hosts that run GCC itself. Second, Sun says that 106950-03 is +only a partial fix for bug 4210064, but Sun doesn't know whether the +partial fix is adequate for GCC. Revision -08 or later should fix +the bug. The current (as of 2001-09-24) revision is -14, and is included in +the Solaris 7 Recommended Patch Cluster. +</ul> + +<p>GCC 3.3 triggers a bug in version 5.0 Alpha 03/27/98 of the Sun assembler, +which causes a bootstrap failure when linking the 64-bit shared version of +libgcc. A typical error message is: + +<br><pre>ld: fatal: relocation error: R_SPARC_32: file libgcc/sparcv9/_muldi3.o: + symbol <unknown>: offset 0xffffffff7ec133e7 is non-aligned. +</pre> + +<p>This bug has been fixed in the final 5.0 version of the assembler. + +<p> +<hr /> + +<h3><a name="TOC59"></a><a name="sparc-sun-sunos4*"></a>sparc-sun-sunos4*</h3> + +<p>Support for this system is obsoleted in GCC 3.3. + +<p>A bug in the SunOS 4 linker will cause it to crash when linking +<code>-fPIC</code> compiled objects (and will therefore not allow you to build +shared libraries). + +<p>To fix this problem you can either use the most recent version of +binutils or get the latest SunOS 4 linker patch (patch ID 100170-10) +from Sun's patch site. + +<p>Sometimes on a Sun 4 you may observe a crash in the program +<code>genflags</code> or <code>genoutput</code> while building GCC. This is said to +be due to a bug in <code>sh</code>. You can probably get around it by running +<code>genflags</code> or <code>genoutput</code> manually and then retrying the +<code>make</code>. + +<hr /> + +<h3><a name="TOC60"></a><a name="sparc-unknown-linux-gnulibc1"></a>sparc-unknown-linux-gnulibc1</h3> + +<p>Support for this system is obsoleted in GCC 3.3. + +<p>It has been reported that you might need +<a href="ftp://ftp.yggdrasil.com/private/hjl">binutils 2.8.1.0.23</a> +for this platform, too. + +<hr /> + +<h3><a name="TOC61"></a><a name="sparc-*-linux*"></a>sparc-*-linux*</h3> + +<p>GCC versions 3.0 and higher require binutils 2.11.2 and glibc 2.2.4 +or newer on this platform. All earlier binutils and glibc +releases mishandled unaligned relocations on <code>sparc-*-*</code> targets. + +<hr /> + +<h3><a name="TOC62"></a><a name="sparc64-*-solaris2*"></a>sparc64-*-solaris2*</h3> + +<p>The following compiler flags must be specified in the configure +step in order to bootstrap this target with the Sun compiler: + +<br><pre> % CC="cc -xildoff -xarch=v9" <var>srcdir</var>/configure [<var>options</var>] [<var>target</var>] +</pre> + +<p><code>-xildoff</code> turns off the incremental linker, and <code>-xarch=v9</code> +specifies the SPARC-V9 architecture to the Sun linker and assembler. + +<hr /> + +<h3><a name="TOC63"></a><a name="sparcv9-*-solaris2*"></a>sparcv9-*-solaris2*</h3> + +<p>This is a synonym for sparc64-*-solaris2*. + +<hr /> + +<h3><a name="TOC64"></a><a name="%23*-*-sysv*"></a>*-*-sysv*</h3> + +<p>On System V release 3, you may get this error message +while linking: + +<br><pre>ld fatal: failed to write symbol name <var>something</var> + in strings table for file <var>whatever</var> +</pre> + +<p>This probably indicates that the disk is full or your ulimit won't allow +the file to be as large as it needs to be. + +<p>This problem can also result because the kernel parameter <code>MAXUMEM</code> +is too small. If so, you must regenerate the kernel and make the value +much larger. The default value is reported to be 1024; a value of 32768 +is said to work. Smaller values may also work. + +<p>On System V, if you get an error like this, + +<br><pre>/usr/local/lib/bison.simple: In function `yyparse': +/usr/local/lib/bison.simple:625: virtual memory exhausted +</pre> + +<p>that too indicates a problem with disk space, ulimit, or <code>MAXUMEM</code>. + +<p>On a System V release 4 system, make sure <code>/usr/bin</code> precedes +<code>/usr/ucb</code> in <code>PATH</code>. The <code>cc</code> command in +<code>/usr/ucb</code> uses libraries which have bugs. + +<hr /> + +<h3><a name="TOC65"></a><a name="vax-dec-ultrix"></a>vax-dec-ultrix</h3> + +<p>Don't try compiling with VAX C (<code>vcc</code>). It produces incorrect code +in some cases (for example, when <code>alloca</code> is used). + +<hr /> + +<h3><a name="TOC66"></a><a name="xtensa-*-elf"></a>xtensa-*-elf</h3> + +<p>This target is intended for embedded Xtensa systems using the +<code>newlib</code> C library. It uses ELF but does not support shared +objects. Designed-defined instructions specified via the +Tensilica Instruction Extension (TIE) language are only supported +through inline assembly. + +<p>The Xtensa configuration information must be specified prior to +building GCC. The <code>gcc/config/xtensa/xtensa-config.h</code> header +file contains the configuration information. If you created your +own Xtensa configuration with the Xtensa Processor Generator, the +downloaded files include a customized copy of this header file, +which you can use to replace the default header file. + +<hr /> + +<h3><a name="TOC67"></a><a name="xtensa-*-linux*"></a>xtensa-*-linux*</h3> + +<p>This target is for Xtensa systems running GNU/Linux. It supports ELF +shared objects and the GNU C library (glibc). It also generates +position-independent code (PIC) regardless of whether the +<code>-fpic</code> or <code>-fPIC</code> options are used. In other +respects, this target is the same as the +<a href="#xtensa-*-elf"><code>xtensa-*-elf</code></a> target. + +<hr /> + +<h3><a name="TOC68"></a><a name="windows"></a>Microsoft Windows (32-bit)</h3> + +<p>A port of GCC 2.95.2 and 3.x is included with the +<a href="http://www.cygwin.com/">Cygwin environment</a>. + +<p>Current (as of early 2001) snapshots of GCC will build under Cygwin +without modification. + +<p>GCC does not currently build with Microsoft's C++ compiler and there +are no plans to make it do so. + +<hr /> + +<h3><a name="TOC69"></a><a name="os2"></a>OS/2</h3> + +<p>GCC does not currently support OS/2. However, Andrew Zabolotny has been +working on a generic OS/2 port with pgcc. The current code can be found +at <a href="http://www.goof.com/pcg/os2/">http://www.goof.com/pcg/os2/</a>. + +<p>An older copy of GCC 2.8.1 is included with the EMX tools available at +<a href="ftp://ftp.leo.org/pub/comp/os/os2/leo/devtools/emx+gcc/">ftp://ftp.leo.org/pub/comp/os/os2/leo/devtools/emx+gcc/</a>. + +<hr /> + +<h3><a name="TOC70"></a><a name="older"></a>Older systems</h3> + +<p>GCC contains support files for many older (1980s and early +1990s) Unix variants. For the most part, support for these systems +has not been deliberately removed, but it has not been maintained for +several years and may suffer from bitrot. + +<p>Starting with GCC 3.1, each release has a list of "obsoleted" systems. +Support for these systems is still present in that release, but +<code>configure</code> will fail unless the <code>--enable-obsolete</code> +option is given. Unless a maintainer steps forward, support for these +systems will be removed from the next release of GCC. + +<p>Support for old systems as hosts for GCC can cause problems if the +workarounds for compiler, library and operating system bugs affect the +cleanliness or maintainability of the rest of GCC. In some cases, to +bring GCC up on such a system, if still possible with current GCC, may +require first installing an old version of GCC which did work on that +system, and using it to compile a more recent GCC, to avoid bugs in the +vendor compiler. Old releases of GCC 1 and GCC 2 are available in the +<code>old-releases</code> directory on the <a href="../mirrors.html">GCC mirror sites</a>. Header bugs may generally be avoided using +<code>fixincludes</code>, but bugs or deficiencies in libraries and the +operating system may still cause problems. + +<p>Support for older systems as targets for cross-compilation is less +problematic than support for them as hosts for GCC; if an enthusiast +wishes to make such a target work again (including resurrecting any of +the targets that never worked with GCC 2, starting from the last CVS +version before they were removed), patches +<a href="../contribute.html">following the usual requirements</a> would be +likely to be accepted, since they should not affect the support for more +modern targets. + +<p>For some systems, old versions of GNU binutils may also be useful, +and are available from <code>pub/binutils/old-releases</code> on +<a href="http://sources.redhat.com/mirrors.html">sources.redhat.com mirror sites</a>. + +<p>Some of the information on specific systems above relates to +such older systems, but much of the information +about GCC on such systems (which may no longer be applicable to +current GCC) is to be found in the GCC texinfo manual. + +<hr /> + +<h3><a name="TOC71"></a><a name="elf_targets"></a>all ELF targets (SVR4, Solaris 2, etc.)</h3> + +<p>C++ support is significantly better on ELF targets if you use the +<a href="./configure.html#with-gnu-ld">GNU linker</a>; duplicate copies of +inlines, vtables and template instantiations will be discarded +automatically. + +<hr /> +<p> +<a href="./index.html">Return to the GCC Installation page</a> + +</body></html> + diff --git a/gnu/usr.bin/gcc/INSTALL/test.html b/gnu/usr.bin/gcc/INSTALL/test.html new file mode 100644 index 00000000000..2abc431384c --- /dev/null +++ b/gnu/usr.bin/gcc/INSTALL/test.html @@ -0,0 +1,162 @@ +<html lang="en"> +<head> +<title>Installing GCC: Testing</title> +<meta http-equiv="Content-Type" content="text/html"> +<meta name=description content="Installing GCC: Testing"> +<meta name=generator content="makeinfo 4.2"> +<link href="http://www.gnu.org/software/texinfo/" rel=generator-home> +<!-- +Copyright © 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, +1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc. +<br><p> +<p>Permission is granted to copy, distribute and/or modify this document +under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no +Invariant Sections, the Front-Cover texts being (a) (see below), and +with the Back-Cover Texts being (b) (see below). A copy of the +license is included in the section entitled "<a href="./gfdl.html">GNU Free Documentation License</a>". + +<p>(a) The FSF's Front-Cover Text is: + +<p>A GNU Manual + +<p>(b) The FSF's Back-Cover Text is: + +<p>You have freedom to copy and modify this GNU Manual, like GNU + software. Copies published by the Free Software Foundation raise + funds for GNU development.--> +</head> +<body> +<h1>Installing GCC: Testing</h1> +Before you install GCC, we encourage you to run the testsuites and to +compare your results with results from a similar configuration that have +been submitted to the +<a href="http://gcc.gnu.org/ml/gcc-testresults/">gcc-testresults mailing list</a>. +Some of these archived results are linked from the build status lists +at <a href="http://gcc.gnu.org/buildstat.html">http://gcc.gnu.org/buildstat.html</a>, although not everyone who +reports a successful build runs the testsuites and submits the results. +This step is optional and may require you to download additional software, +but it can give you confidence in your new GCC installation or point out +problems before you install and start using your new GCC. + +<p>First, you must have <a href="download.html">downloaded the testsuites</a>. +These are part of the full distribution, but if you downloaded the +"core" compiler plus any front ends, you must download the testsuites +separately. + +<p>Second, you must have the testing tools installed. This includes +<a href="http://www.gnu.org/software/dejagnu/">DejaGnu</a> 1.4.1 or 1.4.3 +and later, Tcl, and Expect; the DejaGnu site has links to these. + +<p>If the directories where <code>runtest</code> and <code>expect</code> were +installed are not in the <code>PATH</code>, you may need to set the following +environment variables appropriately, as in the following example (which +assumes that DejaGnu has been installed under <code>/usr/local</code>): + +<br><pre> TCL_LIBRARY = /usr/local/share/tcl8.0 + DEJAGNULIBS = /usr/local/share/dejagnu +</pre> + +<p>(On systems such as Cygwin, these paths are required to be actual +paths, not mounts or links; presumably this is due to some lack of +portability in the DejaGnu code.) + +<p>Finally, you can run the testsuite (which may take a long time): +<br><pre> cd <var>objdir</var>; make -k check +</pre> + +<p>This will test various components of GCC, such as compiler +front ends and runtime libraries. While running the testsuite, DejaGnu +might emit some harmless messages resembling +<code>WARNING: Couldn't find the global config file.</code> or +<code>WARNING: Couldn't find tool init file</code> that can be ignored. + +<h3><a name="TOC0"></a>How can I run the test suite on selected tests?</h3> + +<p>In order to run sets of tests selectively, there are targets +<code>make check-gcc</code> and <code>make check-g++</code> +in the <code>gcc</code> subdirectory of the object directory. You can also +just run <code>make check</code> in a subdirectory of the object directory. + +<p>A more selective way to just run all <code>gcc</code> execute tests in the +testsuite is to use + +<br><pre> make check-gcc RUNTESTFLAGS="execute.exp <var>other-options</var>" +</pre> + +<p>Likewise, in order to run only the <code>g++</code> "old-deja" tests in +the testsuite with filenames matching <code>9805*</code>, you would use + +<br><pre> make check-g++ RUNTESTFLAGS="old-deja.exp=9805* <var>other-options</var>" +</pre> + +<p>The <code>*.exp</code> files are located in the testsuite directories of the GCC +source, the most important ones being <code>compile.exp</code>, +<code>execute.exp</code>, <code>dg.exp</code> and <code>old-deja.exp</code>. +To get a list of the possible <code>*.exp</code> files, pipe the +output of <code>make check</code> into a file and look at the +<code>Running <small>...</small> .exp</code> lines. + +<p>The Java runtime tests can be executed via <code>make check</code> +in the <code><var>target</var>/libjava/testsuite</code> directory in +the build tree. + +<h3><a name="TOC1"></a>Additional testing for Java Class Libraries</h3> + +<p>The <a href="http://sources.redhat.com/mauve/">Mauve Project</a> provides +a suite of tests for the Java Class Libraries. This suite can be run +as part of libgcj testing by placing the Mauve tree within the libjava +testsuite at <code>libjava/testsuite/libjava.mauve/mauve</code>, or by +specifying the location of that tree when invoking <code>make</code>, as in +<code>make MAUVEDIR=~/mauve check</code>. + +<a href="http://www-124.ibm.com/developerworks/oss/cvs/jikes/~checkout~/jacks/jacks.html">Jacks</a> +is a free test suite that tests Java compiler front ends. This suite +can be run as part of libgcj testing by placing the Jacks tree within +the libjava testsuite at <code>libjava/testsuite/libjava.jacks/jacks</code>. + +<h3><a name="TOC2"></a>How to interpret test results</h3> + +<p>The result of running the testsuite are various <code>*.sum</code> and <code>*.log</code> +files in the testsuite subdirectories. The <code>*.log</code> files contain a +detailed log of the compiler invocations and the corresponding +results, the <code>*.sum</code> files summarize the results. These summaries +contain status codes for all tests: + +<ul> +<li>PASS: the test passed as expected +<li>XPASS: the test unexpectedly passed +<li>FAIL: the test unexpectedly failed +<li>XFAIL: the test failed as expected +<li>UNSUPPORTED: the test is not supported on this platform +<li>ERROR: the testsuite detected an error +<li>WARNING: the testsuite detected a possible problem +</ul> + +<p>It is normal for some tests to report unexpected failures. At the +current time our testing harness does not allow fine grained control +over whether or not a test is expected to fail. We expect to fix this +problem in future releases. + +<h3><a name="TOC3"></a>Submitting test results</h3> + +<p>If you want to report the results to the GCC project, use the +<code>contrib/test_summary</code> shell script. Start it in the <var>objdir</var> with + +<br><pre> <var>srcdir</var>/contrib/test_summary -p your_commentary.txt \ + -m gcc-testresults@gcc.gnu.org |sh +</pre> + +<p>This script uses the <code>Mail</code> program to send the results, so +make sure it is in your <code>PATH</code>. The file <code>your_commentary.txt</code> is +prepended to the testsuite summary and should contain any special +remarks you have on your results or your build environment. Please +do not edit the testsuite result block or the subject line, as these +messages may be automatically processed. + +<hr /> +<p> +<a href="./index.html">Return to the GCC Installation page</a> + +</body></html> + |