Context Navigation

source: trunk/src/gcc/INSTALL/specific.html@ 1569

Visit:

Last change on this file since 1569 was 1475, checked in by bird, 21 years ago
This commit was generated by cvs2svn to compensate for changes in r1474, which included commits to RCS files with non-trunk default branches.
Property cvs2svn:cvs-rev set to `1.1.1.3` Property svn:eol-style set to `native` Property svn:executable set to ``*
File size: 74.3 KB

Line
1	<html lang="en">
2	<head>
3	<title>Host/Target specific installation notes for GCC</title>
4	<meta http-equiv="Content-Type" content="text/html">
5	<meta name="description" content="Host/Target specific installation notes for GCC">
6	<meta name="generator" content="makeinfo 4.6">
7	<!--
8	Copyright © 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
9	1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc.
10	<br><p>
11	<p>Permission is granted to copy, distribute and/or modify this document
12	under the terms of the GNU Free Documentation License, Version 1.2 or
13	any later version published by the Free Software Foundation; with no
14	Invariant Sections, the Front-Cover texts being (a) (see below), and
15	with the Back-Cover Texts being (b) (see below). A copy of the
16	license is included in the section entitled "<a href="./gfdl.html">GNU Free Documentation License</a>".
17
18	<p>(a) The FSF's Front-Cover Text is:
19
20	<p>A GNU Manual
21
22	<p>(b) The FSF's Back-Cover Text is:
23
24	<p>You have freedom to copy and modify this GNU Manual, like GNU
25	software. Copies published by the Free Software Foundation raise
26	funds for GNU development.-->
27	<meta http-equiv="Content-Style-Type" content="text/css">
28	<style type="text/css"><!--
29	pre.display { font-family:inherit }
30	pre.format { font-family:inherit }
31	pre.smalldisplay { font-family:inherit; font-size:smaller }
32	pre.smallformat { font-family:inherit; font-size:smaller }
33	pre.smallexample { font-size:smaller }
34	pre.smalllisp { font-size:smaller }
35	--></style>
36	</head>
37	<body>
38	<h1 class="settitle">Host/Target specific installation notes for GCC</h1>
39	Please read this document carefully <em>before</em> installing the
40	GNU Compiler Collection on your machine.
41
42	<ul>
43	<li><a href="#alpha--">alpha--</a>
44	<li><a href="#alpha-dec-osf">alpha-dec-osf</a>
45	<li><a href="#alphaev5-cray-unicosmk">alphaev5-cray-unicosmk</a>
46	<li><a href="#arc--elf">arc--elf</a>
47	<li><a href="#arm--aout">arm--aout</a>
48	<li><a href="#arm--elf">arm--elf</a>
49	<li><a href="#arm--linux-gnu">arm--linux-gnu</a>
50	<li><a href="#avr">avr</a>
51	<li><a href="#c4x">c4x</a>
52	<li><a href="#dos">DOS</a>
53	<li><a href="#dsp16xx">dsp16xx</a>
54	<li><a href="#--freebsd">--freebsd</a>
55	<li><a href="#h8300-hms">h8300-hms</a>
56	<li><a href="#hppa-hp-hpux">hppa-hp-hpux</a>
57	<li><a href="#hppa-hp-hpux9">hppa-hp-hpux9</a>
58	<li><a href="#hppa-hp-hpux10">hppa-hp-hpux10</a>
59	<li><a href="#hppa-hp-hpux11">hppa-hp-hpux11</a>
60	<li><a href="#i370--">i370--</a>
61	<li><a href="#--linux-gnu">--linux-gnu</a>
62	<li><a href="#ix86--linuxaout">i?86--linuxaout</a>
63	<li><a href="#ix86--linux">i?86--linux</a>
64	<li><a href="#ix86--sco">i?86--sco</a>
65	<li><a href="#ix86--sco3.2v4">i?86--sco3.2v4</a>
66	<li><a href="#ix86--sco3.2v5">i?86--sco3.2v5</a>
67	<li><a href="#ix86--udk">i?86--udk</a>
68	<li><a href="#ix86--esix">i?86--esix</a>
69	<li><a href="#ia64--linux">ia64--linux</a>
70	<li><a href="#ia64--hpux">ia64--hpux</a>
71	<li><a href="#-lynx-lynxos">-lynx-lynxos</a>
72	<li><a href="#-ibm-aix">-ibm-aix</a>
73	<li><a href="#ip2k--elf">ip2k--elf</a>
74	<li><a href="#m32r--elf">m32r--elf</a>
75	<li><a href="#m68000-hp-bsd">m68000-hp-bsd</a>
76	<li><a href="#m6811-elf">m6811-elf</a>
77	<li><a href="#m6812-elf">m6812-elf</a>
78	<li><a href="#m68k-att-sysv">m68k-att-sysv</a>
79	<li><a href="#m68k-crds-unos">m68k-crds-unos</a>
80	<li><a href="#m68k-hp-hpux">m68k-hp-hpux</a>
81	<li><a href="#m68k-ncr-">m68k-ncr-</a>
82	<li><a href="#m68k-sun">m68k-sun</a>
83	<li><a href="#m68k-sun-sunos4.1.1">m68k-sun-sunos4.1.1</a>
84	<li><a href="#mips--">mips--</a>
85	<li><a href="#mips-sgi-irix5">mips-sgi-irix5</a>
86	<li><a href="#mips-sgi-irix6">mips-sgi-irix6</a>
87	<li><a href="#powerpc--">powerpc--</a> powerpc-*-sysv4
88	<li><a href="#powerpc--darwin">powerpc--darwin</a>
89	<li><a href="#powerpc--elf">powerpc--elf</a> powerpc-*-sysv4
90	<li><a href="#powerpc--linux-gnu">powerpc--linux-gnu</a>
91	<li><a href="#powerpc--netbsd">powerpc--netbsd</a>
92	<li><a href="#powerpc--eabiaix">powerpc--eabiaix</a>
93	<li><a href="#powerpc--eabisim">powerpc--eabisim</a>
94	<li><a href="#powerpc--eabi">powerpc--eabi</a>
95	<li><a href="#powerpcle--elf">powerpcle--elf</a> powerpcle-*-sysv4
96	<li><a href="#powerpcle--eabisim">powerpcle--eabisim</a>
97	<li><a href="#powerpcle--eabi">powerpcle--eabi</a>
98	<li><a href="#s390--linux">s390--linux</a>
99	<li><a href="#s390x--linux">s390x--linux</a>
100	<li><a href="#--solaris2">--solaris2</a>
101	<li><a href="#sparc-sun-solaris2">sparc-sun-solaris2</a>
102	<li><a href="#sparc-sun-solaris2.7">sparc-sun-solaris2.7</a>
103	<li><a href="#sparc-sun-sunos4">sparc-sun-sunos4</a>
104	<li><a href="#sparc-unknown-linux-gnulibc1">sparc-unknown-linux-gnulibc1</a>
105	<li><a href="#sparc--linux">sparc--linux</a>
106	<li><a href="#sparc64--solaris2">sparc64--solaris2</a>
107	<li><a href="#sparcv9--solaris2">sparcv9--solaris2</a>
108	<li><a href="#--sysv">--sysv</a>
109	<li><a href="#vax-dec-ultrix">vax-dec-ultrix</a>
110	<li><a href="#x86_64--">x86_64--</a> amd64--
111	<li><a href="#xtensa--elf">xtensa--elf</a>
112	<li><a href="#xtensa--linux">xtensa--linux</a>
113	<li><a href="#windows">Microsoft Windows</a>
114	<li><a href="#os2">OS/2</a>
115	<li><a href="#older">Older systems</a>
116	</ul>
117
118	<ul>
119	<li><a href="#elf_targets">all ELF targets</a> (SVR4, Solaris 2, etc.)
120	</ul>
121
122	<!- ------- host/target specific issues start here --------------- ->
123	<hr />
124
125	<h3 class="heading"><a name="TOC0"></a><a name="alpha--"></a>alpha--</h3>
126
127	<p>This section contains general configuration information for all
128	alpha-based platforms using ELF (in particular, ignore this section for
129	DEC OSF/1, Digital UNIX and Tru64 UNIX). In addition to reading this
130	section, please read all other sections that match your target.
131
132	<p>We require binutils 2.11.2 or newer.
133	Previous binutils releases had a number of problems with DWARF 2
134	debugging information, not the least of which is incorrect linking of
135	shared libraries.
136
137	<hr />
138
139	<h3 class="heading"><a name="TOC1"></a><a name="alpha-dec-osf"></a>alpha-dec-osf</h3>
140
141	<p>Systems using processors that implement the DEC Alpha architecture and
142	are running the DEC/Compaq Unix (DEC OSF/1, Digital UNIX, or Compaq
143	Tru64 UNIX) operating system, for example the DEC Alpha AXP systems.
144
145	<p>As of GCC 3.2, versions before <code>alpha*-dec-osf4</code> are no longer
146	supported. (These are the versions which identify themselves as DEC
147	OSF/1.)
148
149	<p>In Digital Unix V4.0, virtual memory exhausted bootstrap failures
150	may be fixed by configuring with <code>--with-gc=simple</code>,
151	reconfiguring Kernel Virtual Memory and Swap parameters
152	per the <code>/usr/sbin/sys_check</code> Tuning Suggestions,
153	or applying the patch in
154	<a href="http://gcc.gnu.org/ml/gcc/2002-08/msg00822.html">http://gcc.gnu.org/ml/gcc/2002-08/msg00822.html</a>.
155
156	<p>In Tru64 UNIX V5.1, Compaq introduced a new assembler that does not
157	currently (2001-06-13) work with <code>mips-tfile</code>. As a workaround,
158	we need to use the old assembler, invoked via the barely documented
159	<code>-oldas</code> option. To bootstrap GCC, you either need to use the
160	Compaq C Compiler:
161
162	<pre class="example"> % CC=cc <var>srcdir</var>/configure [<var>options</var>] [<var>target</var>]
163	</pre>
164
165	<p>or you can use a copy of GCC 2.95.3 or higher built on Tru64 UNIX V4.0:
166
167	<pre class="example"> % CC=gcc -Wa,-oldas <var>srcdir</var>/configure [<var>options</var>] [<var>target</var>]
168	</pre>
169
170	<p>As of GNU binutils 2.11.2, neither GNU <code>as</code> nor GNU <code>ld</code>
171	are supported on Tru64 UNIX, so you must not configure GCC with
172	<code>--with-gnu-as</code> or <code>--with-gnu-ld</code>.
173
174	<p>The <code>--enable-threads</code> options isn't supported yet. A patch is
175	in preparation for a future release.
176
177	<p>GCC writes a <code>.verstamp</code> directive to the assembler output file
178	unless it is built as a cross-compiler. It gets the version to use from
179	the system header file <code>/usr/include/stamp.h</code>. If you install a
180	new version of DEC Unix, you should rebuild GCC to pick up the new version
181	stamp.
182
183	<p>Note that since the Alpha is a 64-bit architecture, cross-compilers from
184	32-bit machines will not generate code as efficient as that generated
185	when the compiler is running on a 64-bit machine because many
186	optimizations that depend on being able to represent a word on the
187	target in an integral value on the host cannot be performed. Building
188	cross-compilers on the Alpha for 32-bit machines has only been tested in
189	a few cases and may not work properly.
190
191	<p><code>make compare</code> may fail on old versions of DEC Unix unless you add
192	<code>-save-temps</code> to <code>CFLAGS</code>. On these systems, the name of the
193	assembler input file is stored in the object file, and that makes
194	comparison fail if it differs between the <code>stage1</code> and
195	<code>stage2</code> compilations. The option <code>-save-temps</code> forces a
196	fixed name to be used for the assembler input file, instead of a
197	randomly chosen name in <code>/tmp</code>. Do not add <code>-save-temps</code>
198	unless the comparisons fail without that option. If you add
199	<code>-save-temps</code>, you will have to manually delete the <code>.i</code> and
200	<code>.s</code> files after each series of compilations.
201
202	<p>GCC now supports both the native (ECOFF) debugging format used by DBX
203	and GDB and an encapsulated STABS format for use only with GDB. See the
204	discussion of the <code>--with-stabs</code> option of <code>configure</code> above
205	for more information on these formats and how to select them.
206
207	<p>There is a bug in DEC's assembler that produces incorrect line numbers
208	for ECOFF format when the <code>.align</code> directive is used. To work
209	around this problem, GCC will not emit such alignment directives
210	while writing ECOFF format debugging information even if optimization is
211	being performed. Unfortunately, this has the very undesirable
212	side-effect that code addresses when <code>-O</code> is specified are
213	different depending on whether or not <code>-g</code> is also specified.
214
215	<p>To avoid this behavior, specify <code>-gstabs+</code> and use GDB instead of
216	DBX. DEC is now aware of this problem with the assembler and hopes to
217	provide a fix shortly.
218
219	<hr />
220
221	<h3 class="heading"><a name="TOC2"></a><a name="alphaev5-cray-unicosmk"></a>alphaev5-cray-unicosmk</h3>
222
223	<p>Cray T3E systems running Unicos/Mk.
224
225	<p>This port is incomplete and has many known bugs. We hope to improve the
226	support for this target soon. Currently, only the C front end is supported,
227	and it is not possible to build parallel applications. Cray modules are not
228	supported; in particular, Craylibs are assumed to be in
229	<code>/opt/ctl/craylibs/craylibs</code>.
230
231	<p>You absolutely <strong>must</strong> use GNU make on this platform. Also, you
232	need to tell GCC where to find the assembler and the linker. The
233	simplest way to do so is by providing <code>--with-as</code> and
234	<code>--with-ld</code> to <code>configure</code>, e.g.
235
236	<pre class="example"> configure --with-as=/opt/ctl/bin/cam --with-ld=/opt/ctl/bin/cld \
237	--enable-languages=c
238	</pre>
239
240	<p>The comparison test during <code>make bootstrap</code> fails on Unicos/Mk
241	because the assembler inserts timestamps into object files. You should
242	be able to work around this by doing <code>make all</code> after getting this
243	failure.
244
245	<hr />
246
247	<h3 class="heading"><a name="TOC3"></a><a name="arc--elf"></a>arc--elf</h3>
248
249	<p>Argonaut ARC processor.
250	This configuration is intended for embedded systems.
251
252	<hr />
253
254	<h3 class="heading"><a name="TOC4"></a><a name="arm--aout"></a>arm--aout</h3>
255
256	<p>This configuration is obsoleted in GCC 3.3.
257
258	<p>Advanced RISC Machines ARM-family processors. These are often used in
259	embedded applications. There are no standard Unix configurations.
260	This configuration corresponds to the basic instruction sequences and will
261	produce <code>a.out</code> format object modules.
262
263	<p>You may need to make a variant of the file <code>arm.h</code> for your particular
264	configuration.
265
266	<hr />
267
268	<h3 class="heading"><a name="TOC5"></a><a name="arm--elf"></a>arm--elf</h3>
269
270	<p>This configuration is intended for embedded systems.
271
272	<hr />
273
274	<h3 class="heading"><a name="TOC6"></a><a name="arm--linux-gnu"></a>arm--linux-gnu</h3>
275
276	<p>We require GNU binutils 2.10 or newer.
277
278	<hr />
279
280	<h3 class="heading"><a name="TOC7"></a><a name="avr"></a>avr</h3>
281
282	<p>ATMEL AVR-family micro controllers. These are used in embedded
283	applications. There are no standard Unix configurations.
284	See "AVR Options" in the main manual
285	for the list of supported MCU types.
286
287	<p>Use <code>configure --target=avr --enable-languages="c"</code> to configure GCC.
288
289	<p>Further installation notes and other useful information about AVR tools
290	can also be obtained from:
291
292	<ul>
293	<li><a href="http://www.openavr.org">http://www.openavr.org</a>
294	<li><a href="http://home.overta.ru/users/denisc/">http://home.overta.ru/users/denisc/</a>
295	<li><a href="http://www.amelek.gda.pl/avr/">http://www.amelek.gda.pl/avr/</a>
296	</ul>
297
298	<p>We <em>strongly</em> recommend using binutils 2.13 or newer.
299
300	<p>The following error:
301	<pre class="example"> Error: register required
302	</pre>
303
304	<p>indicates that you should upgrade to a newer version of the binutils.
305
306	<hr />
307
308	<h3 class="heading"><a name="TOC8"></a><a name="c4x"></a>c4x</h3>
309
310	<p>Texas Instruments TMS320C3x and TMS320C4x Floating Point Digital Signal
311	Processors. These are used in embedded applications. There are no
312	standard Unix configurations.
313	See "TMS320C3x/C4x Options" in the main manual
314	for the list of supported MCU types.
315
316	<p>GCC can be configured as a cross compiler for both the C3x and C4x
317	architectures on the same system. Use <code>configure --target=c4x
318	--enable-languages="c,c++"</code> to configure.
319
320	<p>Further installation notes and other useful information about C4x tools
321	can also be obtained from:
322
323	<ul>
324	<li><a href="http://www.elec.canterbury.ac.nz/c4x/">http://www.elec.canterbury.ac.nz/c4x/</a>
325	</ul>
326
327	<hr />
328
329	<h3 class="heading"><a name="TOC9"></a><a name="cris"></a>CRIS</h3>
330
331	<p>CRIS is the CPU architecture in Axis Communications ETRAX system-on-a-chip
332	series. These are used in embedded applications.
333
334	<p>See "CRIS Options" in the main manual
335	for a list of CRIS-specific options.
336
337	<p>There are a few different CRIS targets:
338	<dl>
339	<dt><code>cris-axis-aout</code>
340	<dd>Old target. Includes a multilib for the <code>elinux</code> a.out-based
341	target. No multilibs for newer architecture variants.
342	<br><dt><code>cris-axis-elf</code>
343	<dd>Mainly for monolithic embedded systems. Includes a multilib for the
344	<code>v10</code> core used in <code>ETRAX 100 LX</code>.
345	<br><dt><code>cris-axis-linux-gnu</code>
346	<dd>A GNU/Linux port for the CRIS architecture, currently targeting
347	<code>ETRAX 100 LX</code> by default.
348	</dl>
349
350	<p>For <code>cris-axis-aout</code> and <code>cris-axis-elf</code> you need binutils 2.11
351	or newer. For <code>cris-axis-linux-gnu</code> you need binutils 2.12 or newer.
352
353	<p>Pre-packaged tools can be obtained from
354	<a href="ftp://ftp.axis.com/pub/axis/tools/cris/compiler-kit/">ftp://ftp.axis.com/pub/axis/tools/cris/compiler-kit/</a>. More
355	information about this platform is available at
356	<a href="http://developer.axis.com/">http://developer.axis.com/</a>.
357
358	<hr />
359
360	<h3 class="heading"><a name="TOC10"></a><a name="dos"></a>DOS</h3>
361
362	<p>Please have a look at our <a href="binaries.html">binaries page</a>.
363
364	<p>You cannot install GCC by itself on MSDOS; it will not compile under
365	any MSDOS compiler except itself. You need to get the complete
366	compilation package DJGPP, which includes binaries as well as sources,
367	and includes all the necessary compilation tools and libraries.
368
369	<hr />
370
371	<h3 class="heading"><a name="TOC11"></a><a name="dsp16xx"></a>dsp16xx</h3>
372
373	<p>A port to the AT&T DSP1610 family of processors.
374
375	<hr />
376
377	<h3 class="heading"><a name="TOC12"></a><a name="--freebsd"></a>--freebsd</h3>
378
379	<p>The version of binutils installed in <code>/usr/bin</code> is known to work unless
380	otherwise specified in any per-architecture notes. However, binutils
381	2.12.1 or greater is known to improve overall testsuite results.
382
383	<p>Support for FreeBSD 1 was discontinued in GCC 3.2.
384
385	<p>For FreeBSD 2 or any mutant a.out versions of FreeBSD 3: All
386	configuration support and files as shipped with GCC 2.95 are still in
387	place. FreeBSD 2.2.7 has been known to bootstrap completely; however,
388	it is unknown which version of binutils was used (it is assumed that it
389	was the system copy in <code>/usr/bin</code>) and C++ EH failures were noted.
390
391	<p>For FreeBSD using the ELF file format: DWARF 2 debugging is now the
392	default for all CPU architectures. It had been the default on
393	FreeBSD/alpha since its inception. You may use <code>-gstabs</code> instead
394	of <code>-g</code>, if you really want the old debugging format. There are
395	no known issues with mixing object files and libraries with different
396	debugging formats. Otherwise, this release of GCC should now match more
397	of the configuration used in the stock FreeBSD configuration of GCC. In
398	particular, <code>--enable-threads</code> is now configured by default.
399	However, as a general user, do not attempt to replace the system
400	compiler with this release. Known to bootstrap and check with good
401	results on FreeBSD 4.8-STABLE and 5-CURRENT. In the past, known to
402	bootstrap and check with good results on FreeBSD 3.0, 3.4, 4.0, 4.2,
403	4.3, 4.4, 4.5-STABLE.
404
405	<p>In principle, <code>--enable-threads</code> is now compatible with
406	<code>--enable-libgcj</code> on FreeBSD. However, it has only been built
407	and tested on <code>i386--freebsd[45]</code> and <code>alpha--freebsd[45]</code>.
408	The static
409	library may be incorrectly built (symbols are missing at link time).
410	There is a rare timing-based startup hang (probably involves an
411	assumption about the thread library). Multi-threaded boehm-gc (required for
412	libjava) exposes severe threaded signal-handling bugs on FreeBSD before
413	4.5-RELEASE. Other CPU architectures
414	supported by FreeBSD will require additional configuration tuning in, at
415	the very least, both boehm-gc and libffi.
416
417	<p>Shared <code>libgcc_s.so</code> is now built and installed by default.
418
419	<hr />
420
421	<h3 class="heading"><a name="TOC13"></a><a name="h8300-hms"></a>h8300-hms</h3>
422
423	<p>Renesas H8/300 series of processors.
424
425	<p>Please have a look at our <a href="binaries.html">binaries page</a>.
426
427	<p>The calling convention and structure layout has changed in release 2.6.
428	All code must be recompiled. The calling convention now passes the
429	first three arguments in function calls in registers. Structures are no
430	longer a multiple of 2 bytes.
431
432	<hr />
433
434	<h3 class="heading"><a name="TOC14"></a><a name="hppa-hp-hpux"></a>hppa-hp-hpux</h3>
435
436	<p>Support for HP-UX versions 7, 8, and 9 is obsoleted in GCC 3.3.
437
438	<p>We <em>highly</em> recommend using gas/binutils 2.8 or newer on all hppa
439	platforms; you may encounter a variety of problems when using the HP
440	assembler.
441
442	<p>Specifically, <code>-g</code> does not work on HP-UX (since that system
443	uses a peculiar debugging format which GCC does not know about), unless you
444	use GAS and GDB and configure GCC with the
445	<a href="./configure.html#with-gnu-as"><code>--with-gnu-as</code></a> and
446	<code>--with-as=...</code> options.
447
448	<p>If you wish to use the pa-risc 2.0 architecture support with a 32-bit
449	runtime, you must use either the HP assembler, gas/binutils 2.11 or newer,
450	or a recent
451	<a href="ftp://sources.redhat.com/pub/binutils/snapshots">snapshot of gas</a>.
452
453	<p>There are two default scheduling models for instructions. These are
454	PROCESSOR_7100LC and PROCESSOR_8000. They are selected from the pa-risc
455	architecture specified for the target machine when configuring.
456	PROCESSOR_8000 is the default. PROCESSOR_7100LC is selected when
457	the target is a <code>hppa1*</code> machine.
458
459	<p>The PROCESSOR_8000 model is not well suited to older processors. Thus,
460	it is important to completely specify the machine architecture when
461	configuring if you want a model other than PROCESSOR_8000. The macro
462	TARGET_SCHED_DEFAULT can be defined in BOOT_CFLAGS if a different
463	default scheduling model is desired.
464
465	<p>More specific information to <code>hppa-hp-hpux</code> targets follows.
466
467	<hr />
468
469	<h3 class="heading"><a name="TOC15"></a><a name="hppa-hp-hpux9"></a>hppa-hp-hpux9</h3>
470
471	<p>Support for this system is obsoleted in GCC 3.3.
472
473	<p>The HP assembler has major problems on this platform. We've tried to work
474	around the worst of the problems. However, those workarounds may be causing
475	linker crashes in some circumstances; the workarounds also probably prevent
476	shared libraries from working. Use the GNU assembler to avoid these problems.
477
478	<p>The configuration scripts for GCC will also trigger a bug in the hpux9
479	shell. To avoid this problem set <code>CONFIG_SHELL</code> to <code>/bin/ksh</code>
480	and <code>SHELL</code> to <code>/bin/ksh</code> in your environment.
481
482	<hr />
483
484	<h3 class="heading"><a name="TOC16"></a><a name="hppa-hp-hpux10"></a>hppa-hp-hpux10</h3>
485
486	<p>For hpux10.20, we <em>highly</em> recommend you pick up the latest sed patch
487	<code>PHCO_19798</code> from HP. HP has two sites which provide patches free of
488	charge:
489
490	<ul>
491	<li><a href="http://us.itrc.hp.com/service/home/home.do">US, Canada, Asia-Pacific, and
492	Latin-America</a>
493	<li><a href="http://europe.itrc.hp.com/service/home/home.do">http://europe.itrc.hp.com/service/home/home.do</a> Europe.
494	</ul>
495
496	<p>The HP assembler on these systems is much better than the hpux9 assembler,
497	but still has some problems. Most notably the assembler inserts timestamps
498	into each object file it creates, causing the 3-stage comparison test to fail
499	during a <code>make bootstrap</code>. You should be able to continue by
500	saying <code>make all</code> after getting the failure from <code>make
501	bootstrap</code>.
502
503	<hr />
504
505	<h3 class="heading"><a name="TOC17"></a><a name="hppa-hp-hpux11"></a>hppa-hp-hpux11</h3>
506
507	<p>GCC 3.0 and up support HP-UX 11. On 64-bit capable systems, there
508	are two distinct ports. The <code>hppa2.0w-hp-hpux11*</code> port generates
509	code for the 32-bit pa-risc runtime architecture. It uses the HP
510	linker. The <code>hppa64-hp-hpux11*</code> port generates 64-bit code for the
511	pa-risc 2.0 architecture. The script config.guess now selects the port
512	type based on the type compiler detected during configuration. You must
513	set your <code>PATH</code> or define <code>CC</code> so that configure finds an appropriate
514	compiler for the initial bootstrap. Different prefixes must be used if
515	both ports are to be installed on the same system.
516
517	<p>It is best to explicitly configure the <code>hppa64-hp-hpux11*</code> target
518	with the <code>--with-ld=...</code> option. We support both the HP
519	and GNU linkers for this target. The two linkers require different
520	link commands. Thus, it's not possible to switch linkers during a
521	GCC build. This has been been reported to occur in a unified build
522	of binutils and GCC.
523
524	<p>GCC 2.95.x is not supported under HP-UX 11 and cannot be used to
525	compile GCC 3.0 and up. Refer to <a href="binaries.html">binaries</a> for
526	information about obtaining precompiled GCC binaries for HP-UX.
527
528	<p>You must use GNU binutils 2.11 or above with the 32-bit port. Thread
529	support is not currently implemented, so <code>--enable-threads</code> does
530	not work. See:
531
532	<ul>
533	<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>
534	<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>
535	</ul>
536
537	<p>GCC 3.3 and later support weak symbols on the 32-bit port using SOM
538	secondary definition symbols. This feature is not enabled for earlier
539	versions of HP-UX since there have been bugs in the linker support for
540	secondary symbols. The HP linker patches <code>PHSS_26559</code> and
541	<code>PHSS_24304</code> for HP-UX 11.00 and 11.11, respectively, correct the
542	problem of linker core dumps creating C++ libraries. Earlier patches
543	may work but they have not been tested.
544
545	<p>GCC 3.3 nows uses the ELF DT_INIT_ARRAY and DT_FINI_ARRAY capability
546	to run initializers and finalizers on the 64-bit port. The feature
547	requires CVS binutils as of January 2, 2003, or a subsequent release
548	to correct a problem arising from HP's non-standard use of the .init
549	and .fini sections. The 32-bit port uses the linker <code>+init</code>
550	and <code>+fini</code> options. As with the support for secondary symbols,
551	there have been bugs in the order in which these options are executed
552	by the HP linker. So, again a recent linker patch is recommended.
553
554	<p>The HP assembler has many limitations and is not recommended for either
555	the 32 or 64-bit ports. For example, it does not support weak symbols
556	or alias definitions. As a result, explicit template instantiations
557	are required when using C++. This will make it difficult if not
558	impossible to build many C++ applications. You also can't generate
559	debugging information when using the HP assembler with GCC.
560
561	<p>There are a number of issues to consider in selecting which linker to
562	use with the 64-bit port. The GNU 64-bit linker can only create dynamic
563	binaries. The <code>-static</code> option causes linking with archive
564	libraries but doesn't produce a truly static binary. Dynamic binaries
565	still require final binding by the dynamic loader to resolve a set of
566	dynamic-loader-defined symbols. The default behavior of the HP linker
567	is the same as the GNU linker. However, it can generate true 64-bit
568	static binaries using the <code>+compat</code> option.
569
570	<p>The HP 64-bit linker doesn't support linkonce semantics. As a
571	result, C++ programs have many more sections than they should.
572
573	<p>The GNU 64-bit linker has some issues with shared library support
574	and exceptions. As a result, we only support libgcc in archive
575	format. For similar reasons, dwarf2 unwind and exception support
576	are disabled. The GNU linker also has problems creating binaries
577	with <code>-static</code>. It doesn't provide stubs for internal
578	calls to global functions in shared libraries, so these calls
579	can't be overloaded.
580
581	<p>There are several possible approaches to building the distribution.
582	Binutils can be built first using the HP tools. Then, the GCC
583	distribution can be built. The second approach is to build GCC
584	first using the HP tools, then build binutils, then rebuild GCC.
585	There have been problems with various binary distributions, so
586	it is best not to start from a binary distribution.
587
588	<p>When starting with a HP compiler, it is preferable to use the ANSI
589	compiler as the bundled compiler only supports traditional C.
590	Bootstrapping with the bundled compiler is tested infrequently and
591	problems often arise because of the subtle differences in semantics
592	between traditional and ISO C.
593
594	<p>This port still is undergoing significant development.
595
596	<hr />
597
598	<h3 class="heading"><a name="TOC18"></a><a name="i370--"></a>i370--</h3>
599
600	<p>This port is very preliminary and has many known bugs. We hope to
601	have a higher-quality port for this machine soon.
602
603	<hr />
604
605	<h3 class="heading"><a name="TOC19"></a><a name="--linux-gnu"></a>--linux-gnu</h3>
606
607	<p>Versions of libstdc++-v3 starting with 3.2.1 require bugfixes present
608	in glibc 2.2.5 and later. More information is available in the
609	libstdc++-v3 documentation.
610
611	<p>If you use glibc 2.2 (or 2.1.9x), GCC 2.95.2 won't install
612	out-of-the-box. You'll get compile errors while building <code>libstdc++</code>.
613	The patch <a href="glibc-2.2.patch">glibc-2.2.patch</a>, that is to be
614	applied in the GCC source tree, fixes the compatibility problems.
615
616	<p>Currently Glibc 2.2.3 (and older releases) and GCC 3.0 are out of sync
617	since the latest exception handling changes for GCC. Compiling glibc
618	with GCC 3.0 will give a binary incompatible glibc and therefore cause
619	lots of problems and might make your system completely unusable. This
620	will definitely need fixes in glibc but might also need fixes in GCC. We
621	strongly advise to wait for glibc 2.2.4 and to read the release notes of
622	glibc 2.2.4 whether patches for GCC 3.0 are needed. You can use glibc
623	2.2.3 with GCC 3.0, just do not try to recompile it.
624
625	<hr />
626
627	<h3 class="heading"><a name="TOC20"></a><a name="ix86--linuxaout"></a>i?86--linuxaout</h3>
628
629	<p>Use this configuration to generate <code>a.out</code> binaries on Linux-based
630	GNU systems. This configuration is being superseded. You must use
631	gas/binutils version 2.5.2 or later.
632
633	<hr />
634
635	<h3 class="heading"><a name="TOC21"></a><a name="ix86--linux"></a>i?86--linux</h3>
636
637	<p>As of GCC 3.3, binutils 2.13.1 or later is required for this platform.
638	See <a href="http://gcc.gnu.org/PR10877">bug 10877</a> for more information.
639
640	<p>If you receive Signal 11 errors when building on GNU/Linux, then it is
641	possible you have a hardware problem. Further information on this can be
642	found on <a href="http://www.bitwizard.nl/sig11/">www.bitwizard.nl</a>.
643
644	<hr />
645
646	<h3 class="heading"><a name="TOC22"></a><a name="ix86--sco"></a>i?86--sco</h3>
647
648	<p>Compilation with RCC is recommended. Also, it may be a good idea to
649	link with GNU malloc instead of the malloc that comes with the system.
650
651	<hr />
652
653	<h3 class="heading"><a name="TOC23"></a><a name="ix86--sco3.2v5"></a>i?86--sco3.2v5</h3>
654
655	<p>Use this for the SCO OpenServer Release 5 family of operating systems.
656
657	<p>Unlike earlier versions of GCC, the ability to generate COFF with this
658	target is no longer provided.
659
660	<p>Earlier versions of GCC emitted DWARF 1 when generating ELF to allow
661	the system debugger to be used. That support was too burdensome to
662	maintain. GCC now emits only DWARF 2 for this target. This means you
663	may use either the UDK debugger or GDB to debug programs built by this
664	version of GCC.
665
666	<p>GCC is now only supported on releases 5.0.4 and later, and requires that
667	you install Support Level Supplement OSS646B or later, and the latest
668	version of the Supplement Graphics, Web and X11 Libraries (GWXLIBS)
669	package. If you are using release 5.0.7 of OpenServer, you must have at
670	least the first maintenance pack installed (this includes the relevant
671	portions of OSS646 and GWXLIBS). OSS646, also known as the "Execution
672	Environment Update", provides updated link editors and assemblers, as well
673	as updated standard C and math libraries. The C startup modules are also
674	updated to support the System V gABI draft, and GCC relies on that
675	behavior. GWXLIBS provides a collection of commonly used open source
676	libraries, some of which GCC depends on (such as GNU gettext and zlib).
677	SCO OpenServer Release 5.0.7 has all of this built in by default, but
678	GWXLIBS is significantly updated in Maintenance Pack 1. Please visit
679	<a href="ftp://ftp.sco.com/pub/openserver5">ftp://ftp.sco.com/pub/openserver5</a>
680	and
681	<a href="ftp://ftp.sco.com/pub/openserver5/opensrc">ftp://ftp.sco.com/pub/openserver5/opensrc</a>
682	for the latest versions of these (and other potentially useful) supplements.
683
684	<p>Although there is support for using the native assembler, it is recommended
685	that you configure GCC to use the GNU assembler. You do this by using the
686	flags <a href="./configure.html#with-gnu-as"><code>--with-gnu-as</code></a>. You
687	should use a modern version of GNU binutils. Version 2.14 was used for all
688	testing. In general, only the <code>--with-gnu-as</code> option is tested. A
689	modern bintuils (as well as a plethora of other development related GNU
690	utilities) can be found in the GNU Development Tools package. See the
691	SCO web and ftp sites for details. That package also contains the
692	currently "officially supported" version of GCC, version 2.95.3. It is
693	useful for bootstrapping this version.
694
695	<hr />
696
697	<h3 class="heading"><a name="TOC24"></a><a name="ix86--udk"></a>i?86--udk</h3>
698
699	<p>This target emulates the SCO Universal Development Kit and requires that
700	package be installed. (If it is installed, you will have a
701	<code>/udk/usr/ccs/bin/cc</code> file present.) It's very much like the
702	<code>i?86--unixware7</code> target
703	but is meant to be used when hosting on a system where UDK isn't the
704	default compiler such as OpenServer 5 or Unixware 2. This target will
705	generate binaries that will run on OpenServer, Unixware 2, or Unixware 7,
706	with the same warnings and caveats as the SCO UDK.
707
708	<p>This target is a little tricky to build because we have to distinguish
709	it from the native tools (so it gets headers, startups, and libraries
710	from the right place) while making the tools not think we're actually
711	building a cross compiler. The easiest way to do this is with a configure
712	command like this:
713
714	<pre class="example"> CC=/udk/usr/ccs/bin/cc <var>/your/path/to</var>/gcc/configure \
715	--host=i686-pc-udk --target=i686-pc-udk --program-prefix=udk-
716	</pre>
717
718	<p><em>You should substitute </em><code>i686</code><em> in the above command with the appropriate
719	processor for your host.</em>
720
721	<p>After the usual <code>make bootstrap</code> and
722	<code>make install</code>, you can then access the UDK-targeted GCC
723	tools by adding <code>udk-</code> before the commonly known name. For
724	example, to invoke the C compiler, you would use <code>udk-gcc</code>.
725	They will coexist peacefully with any native-target GCC tools you may
726	have installed.
727
728	<hr />
729
730	<h3 class="heading"><a name="TOC25"></a><a name="ia64--linux"></a>ia64--linux</h3>
731
732	<p>IA-64 processor (also known as IPF, or Itanium Processor Family)
733	running GNU/Linux.
734
735	<p>The toolchain is not completely finished, so requirements will continue
736	to change.
737	GCC 3.0.1 and later require glibc 2.2.4.
738	GCC 3.0.2 requires binutils from 2001-09-05 or later.
739	GCC 3.0.1 requires binutils 2.11.1 or later.
740
741	<p>None of the following versions of GCC has an ABI that is compatible
742	with any of the other versions in this list, with the exception that
743	Red Hat 2.96 and Trillian 000171 are compatible with each other:
744	3.0.2, 3.0.1, 3.0, Red Hat 2.96, and Trillian 000717.
745	This primarily affects C++ programs and programs that create shared libraries.
746	Because of these ABI incompatibilities, GCC 3.0.2 is not recommended for
747	user programs on GNU/Linux systems built using earlier compiler releases.
748	GCC 3.0.2 is recommended for compiling linux, the kernel.
749	GCC 3.0.2 is believed to be fully ABI compliant, and hence no more major
750	ABI changes are expected.
751
752	<hr />
753
754	<h3 class="heading"><a name="TOC26"></a><a name="ia64--hpux"></a>ia64--hpux</h3>
755
756	<p>Building GCC on this target requires the GNU Assembler. The bundled HP
757	assembler will not work. To prevent GCC from using the wrong assembler,
758	the option <code>--with-gnu-as</code> may be necessary.
759
760	<p>The GCC libunwind library has not been ported to HPUX. This means that for
761	GCC versions 3.2.3 and earlier, <code>--enable-libunwind-exceptions</code>
762	is required to build GCC. For GCC 3.3 and later, this is the default.
763
764	<hr />
765
766	<h3 class="heading"><a name="TOC27"></a><a name="-lynx-lynxos"></a>-lynx-lynxos</h3>
767
768	<p>Support for SPARC LynxOS is obsoleted in GCC 3.3.
769
770	<p>LynxOS 2.2 and earlier comes with GCC 1.x already installed as
771	<code>/bin/gcc</code>. You should compile with this instead of <code>/bin/cc</code>.
772	You can tell GCC to use the GNU assembler and linker, by specifying
773	<code>--with-gnu-as --with-gnu-ld</code> when configuring. These will produce
774	COFF format object files and executables; otherwise GCC will use the
775	installed tools, which produce <code>a.out</code> format executables.
776
777	<hr />
778	<!- rs6000-ibm-aix, powerpc-ibm-aix ->
779
780	<h3 class="heading"><a name="TOC28"></a><a name="-ibm-aix"></a>-ibm-aix</h3>
781
782	<p>Support for AIX versions 1, 2, and 3 is obsoleted in GCC 3.3.
783
784	<p>AIX Make frequently has problems with GCC makefiles. GNU Make 3.76 or
785	newer is recommended to build on this platform.
786
787	<p>Errors involving <code>alloca</code> when building GCC generally are due
788	to an incorrect definition of <code>CC</code> in the Makefile or mixing files
789	compiled with the native C compiler and GCC. During the stage1 phase of
790	the build, the native AIX compiler <strong>must</strong> be invoked as <code>cc</code>
791	(not <code>xlc</code>). Once <code>configure</code> has been informed of
792	<code>xlc</code>, one needs to use <code>make distclean</code> to remove the
793	configure cache files and ensure that <code>CC</code> environment variable
794	does not provide a definition that will confuse <code>configure</code>.
795	If this error occurs during stage2 or later, then the problem most likely
796	is the version of Make (see above).
797
798	<p>The native <code>as</code> and <code>ld</code> are recommended for bootstrapping
799	on AIX 4 and required for bootstrapping on AIX 5L. The GNU Assembler
800	reports that it supports WEAK symbols on AIX 4, which causes GCC to try to
801	utilize weak symbol functionality although it is not supported. The GNU
802	Assembler and Linker do not support AIX 5L sufficiently to bootstrap GCC.
803	The native AIX tools do interoperate with GCC.
804
805	<p>Building <code>libstdc++.a</code> requires a fix for an AIX Assembler bug
806	APAR IY26685 (AIX 4.3) or APAR IY25528 (AIX 5.1).
807
808	<p><code>libstdc++</code> in GCC 3.2 increments the major version number of the
809	shared object and GCC installation places the <code>libstdc++.a</code>
810	shared library in a common location which will overwrite the GCC 3.1
811	version of the shared library. Applications either need to be
812	re-linked against the new shared library or the GCC 3.1 version of the
813	<code>libstdc++</code> shared object needs to be available to the AIX
814	runtime loader. The GCC 3.1 <code>libstdc++.so.4</code> shared object can
815	be installed for runtime dynamic loading using the following steps to
816	set the <code>F_LOADONLY</code> flag in the shared object for <em>each</em>
817	multilib <code>libstdc++.a</code> installed:
818
819	<p>Extract the shared object from each the GCC 3.1 <code>libstdc++.a</code>
820	archive:
821	<pre class="example"> % ar -x libstdc++.a libstdc++.so.4
822	</pre>
823
824	<p>Enable the <code>F_LOADONLY</code> flag so that the shared object will be
825	available for runtime dynamic loading, but not linking:
826	<pre class="example"> % strip -e libstdc++.so.4
827	</pre>
828
829	<p>Archive the runtime-only shared object in the GCC 3.2
830	<code>libstdc++.a</code> archive:
831	<pre class="example"> % ar -q libstdc++.a libstdc++.so.4
832	</pre>
833
834	<p>Linking executables and shared libraries may produce warnings of
835	duplicate symbols. The assembly files generated by GCC for AIX always
836	have included multiple symbol definitions for certain global variable
837	and function declarations in the original program. The warnings should
838	not prevent the linker from producing a correct library or runnable
839	executable.
840
841	<p>AIX 4.3 utilizes a "large format" archive to support both 32-bit and
842	64-bit object modules. The routines provided in AIX 4.3.0 and AIX 4.3.1
843	to parse archive libraries did not handle the new format correctly.
844	These routines are used by GCC and result in error messages during
845	linking such as "not a COFF file". The version of the routines shipped
846	with AIX 4.3.1 should work for a 32-bit environment. The <code>-g</code>
847	option of the archive command may be used to create archives of 32-bit
848	objects using the original "small format". A correct version of the
849	routines is shipped with AIX 4.3.2 and above.
850
851	<p>Some versions of the AIX binder (linker) can fail with a relocation
852	overflow severe error when the <code>-bbigtoc</code> option is used to link
853	GCC-produced object files into an executable that overflows the TOC. A fix
854	for APAR IX75823 (OVERFLOW DURING LINK WHEN USING GCC AND -BBIGTOC) is
855	available from IBM Customer Support and from its
856	<a href="http://techsupport.services.ibm.com/">techsupport.services.ibm.com</a>
857	website as PTF U455193.
858
859	<p>The AIX 4.3.2.1 linker (bos.rte.bind_cmds Level 4.3.2.1) will dump core
860	with a segmentation fault when invoked by any version of GCC. A fix for
861	APAR IX87327 is available from IBM Customer Support and from its
862	<a href="http://techsupport.services.ibm.com/">techsupport.services.ibm.com</a>
863	website as PTF U461879. This fix is incorporated in AIX 4.3.3 and above.
864
865	<p>The initial assembler shipped with AIX 4.3.0 generates incorrect object
866	files. A fix for APAR IX74254 (64BIT DISASSEMBLED OUTPUT FROM COMPILER FAILS
867	TO ASSEMBLE/BIND) is available from IBM Customer Support and from its
868	<a href="http://techsupport.services.ibm.com/">techsupport.services.ibm.com</a>
869	website as PTF U453956. This fix is incorporated in AIX 4.3.1 and above.
870
871	<p>AIX provides National Language Support (NLS). Compilers and assemblers
872	use NLS to support locale-specific representations of various data
873	formats including floating-point numbers (e.g., <code>.</code> vs <code>,</code> for
874	separating decimal fractions). There have been problems reported where
875	GCC does not produce the same floating-point formats that the assembler
876	expects. If one encounters this problem, set the <code>LANG</code>
877	environment variable to <code>C</code> or <code>En_US</code>.
878
879	<p>By default, GCC for AIX 4.1 and above produces code that can be used on
880	both Power or PowerPC processors.
881
882	<p>A default can be specified with the <code>-mcpu=</code><var>cpu_type</var><code></code>
883	switch and using the configure option <code>--with-cpu-</code><var>cpu_type</var><code></code>.
884
885	<hr />
886
887	<h3 class="heading"><a name="TOC29"></a><a name="ip2k--elf"></a>ip2k--elf</h3>
888
889	<p>Ubicom IP2022 micro controller.
890	This configuration is intended for embedded systems.
891	There are no standard Unix configurations.
892
893	<p>Use <code>configure --target=ip2k-elf --enable-languages=c</code> to configure GCC.
894
895	<hr />
896
897	<h3 class="heading"><a name="TOC30"></a><a name="m32r--elf"></a>m32r--elf</h3>
898
899	<p>Renesas M32R processor.
900	This configuration is intended for embedded systems.
901
902	<hr />
903
904	<h3 class="heading"><a name="TOC31"></a><a name="m68000-hp-bsd"></a>m68000-hp-bsd</h3>
905
906	<p>Support for this system is obsoleted in GCC 3.3.
907
908	<p>HP 9000 series 200 running BSD. Note that the C compiler that comes
909	with this system cannot compile GCC; contact <a href="mailto:law@cygnus.com">law@cygnus.com</a>
910	to get binaries of GCC for bootstrapping.
911
912	<hr />
913
914	<h3 class="heading"><a name="TOC32"></a><a name="m6811-elf"></a>m6811-elf</h3>
915
916	<p>Motorola 68HC11 family micro controllers. These are used in embedded
917	applications. There are no standard Unix configurations.
918
919	<hr />
920
921	<h3 class="heading"><a name="TOC33"></a><a name="m6812-elf"></a>m6812-elf</h3>
922
923	<p>Motorola 68HC12 family micro controllers. These are used in embedded
924	applications. There are no standard Unix configurations.
925
926	<hr />
927
928	<h3 class="heading"><a name="TOC34"></a><a name="m68k-att-sysv"></a>m68k-att-sysv</h3>
929
930	<p>Support for this system is obsoleted in GCC 3.3.
931
932	<p>AT&T 3b1, a.k.a. 7300 PC. This version of GCC cannot
933	be compiled with the system C compiler, which is too buggy.
934	You will need to get a previous version of GCC and use it to
935	bootstrap. Binaries are available from the OSU-CIS archive, at
936	<a href="ftp://ftp.uu.net/systems/att7300/">ftp://ftp.uu.net/systems/att7300/</a>.
937
938	<hr />
939
940	<h3 class="heading"><a name="TOC35"></a><a name="m68k-crds-unos"></a>m68k-crds-unos</h3>
941
942	<p>Support for this system is obsoleted in GCC 3.3.
943
944	<p>Use <code>configure unos</code> for building on Unos.
945
946	<p>The Unos assembler is named <code>casm</code> instead of <code>as</code>. For some
947	strange reason linking <code>/bin/as</code> to <code>/bin/casm</code> changes the
948	behavior, and does not work. So, when installing GCC, you should
949	install the following script as <code>as</code> in the subdirectory where
950	the passes of GCC are installed:
951
952	<pre class="example"> #!/bin/sh
953	casm $*
954	</pre>
955
956	<p>The default Unos library is named <code>libunos.a</code> instead of
957	<code>libc.a</code>. To allow GCC to function, either change all
958	references to <code>-lc</code> in <code>gcc.c</code> to <code>-lunos</code> or link
959	<code>/lib/libc.a</code> to <code>/lib/libunos.a</code>.
960
961	<p>When compiling GCC with the standard compiler, to overcome bugs in
962	the support of <code>alloca</code>, do not use <code>-O</code> when making stage 2.
963	Then use the stage 2 compiler with <code>-O</code> to make the stage 3
964	compiler. This compiler will have the same characteristics as the usual
965	stage 2 compiler on other systems. Use it to make a stage 4 compiler
966	and compare that with stage 3 to verify proper compilation.
967
968	<p>(Perhaps simply defining <code>ALLOCA</code> in <code>x-crds</code> as described in
969	the comments there will make the above paragraph superfluous. Please
970	inform us of whether this works.)
971
972	<p>Unos uses memory segmentation instead of demand paging, so you will need
973	a lot of memory. 5 Mb is barely enough if no other tasks are running.
974	If linking <code>cc1</code> fails, try putting the object files into a library
975	and linking from that library.
976
977	<hr />
978
979	<h3 class="heading"><a name="TOC36"></a><a name="m68k-hp-hpux"></a>m68k-hp-hpux</h3>
980
981	<p>HP 9000 series 300 or 400 running HP-UX. HP-UX version 8.0 has a bug in
982	the assembler that prevents compilation of GCC. This
983	bug manifests itself during the first stage of compilation, while
984	building <code>libgcc2.a</code>:
985
986	<pre class="smallexample"> _floatdisf
987	cc1: warning: `-g' option not supported on this version of GCC
988	cc1: warning: `-g1' option not supported on this version of GCC
989	./xgcc: Internal compiler error: program as got fatal signal 11
990	</pre>
991
992	<p>A patched version of the assembler is available as the file
993	<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
994	have HP software support, the patch can also be obtained directly from
995	HP, as described in the following note:
996
997	<blockquote>
998	This is the patched assembler, to patch SR#1653-010439, where the
999	assembler aborts on floating point constants.
1000
1001	<p>The bug is not really in the assembler, but in the shared library
1002	version of the function "cvtnum(3c)". The bug on "cvtnum(3c)" is
1003	SR#4701-078451. Anyway, the attached assembler uses the archive
1004	library version of "cvtnum(3c)" and thus does not exhibit the bug.
1005	</blockquote>
1006
1007	<p>This patch is also known as PHCO_4484.
1008
1009	<p>In addition, if you wish to use gas, you must use
1010	gas version 2.1 or later, and you must use the GNU linker version 2.1 or
1011	later. Earlier versions of gas relied upon a program which converted the
1012	gas output into the native HP-UX format, but that program has not been
1013	kept up to date. gdb does not understand that native HP-UX format, so
1014	you must use gas if you wish to use gdb.
1015
1016	<p>On HP-UX version 8.05, but not on 8.07 or more recent versions, the
1017	<code>fixproto</code> shell script triggers a bug in the system shell. If you
1018	encounter this problem, upgrade your operating system or use BASH (the
1019	GNU shell) to run <code>fixproto</code>. This bug will cause the fixproto
1020	program to report an error of the form:
1021
1022	<pre class="example"> ./fixproto: sh internal 1K buffer overflow
1023	</pre>
1024
1025	<p>To fix this, you can also change the first line of the fixproto script
1026	to look like:
1027
1028	<pre class="example"> #!/bin/ksh
1029	</pre>
1030
1031	<hr />
1032
1033	<h3 class="heading"><a name="TOC37"></a><a name="m68k-ncr-"></a>m68k-ncr-</h3>
1034
1035	<p>Support for this system is obsoleted in GCC 3.3.
1036
1037	<p>On the Tower models 4<var>n</var>0 and 6<var>n</var>0, by default a process is not
1038	allowed to have more than one megabyte of memory. GCC cannot compile
1039	itself (or many other programs) with <code>-O</code> in that much memory.
1040
1041	<p>To solve this problem, reconfigure the kernel adding the following line
1042	to the configuration file:
1043
1044	<pre class="smallexample"> MAXUMEM = 4096
1045	</pre>
1046
1047	<hr />
1048
1049	<h3 class="heading"><a name="TOC38"></a><a name="m68k-sun"></a>m68k-sun</h3>
1050
1051	<p>Support for this system is obsoleted in GCC 3.3.
1052
1053	<p>Sun 3. We do not provide a configuration file to use the Sun FPA by
1054	default, because programs that establish signal handlers for floating
1055	point traps inherently cannot work with the FPA.
1056
1057	<hr />
1058
1059	<h3 class="heading"><a name="TOC39"></a><a name="m68k-sun-sunos4.1.1"></a>m68k-sun-sunos4.1.1</h3>
1060
1061	<p>Support for this system is obsoleted in GCC 3.3.
1062
1063	<p>It is reported that you may need the GNU assembler on this platform.
1064
1065	<hr />
1066
1067	<h3 class="heading"><a name="TOC40"></a><a name="mips--"></a>mips--</h3>
1068
1069	<p>If on a MIPS system you get an error message saying "does not have gp
1070	sections for all it's [sic] sectons [sic]", don't worry about it. This
1071	happens whenever you use GAS with the MIPS linker, but there is not
1072	really anything wrong, and it is okay to use the output file. You can
1073	stop such warnings by installing the GNU linker.
1074
1075	<p>It would be nice to extend GAS to produce the gp tables, but they are
1076	optional, and there should not be a warning about their absence.
1077
1078	<p>The libstdc++ atomic locking routines for MIPS targets requires MIPS II
1079	and later. A patch went in just after the GCC 3.3 release to
1080	make <code>mips--*</code> use the generic implementation instead. You can also
1081	configure for <code>mipsel-elf</code> as a workaround. The
1082	<code>mips--linux*</code> target continues to use the MIPS II routines. More
1083	work on this is expected in future releases.
1084
1085	<hr />
1086
1087	<h3 class="heading"><a name="TOC41"></a><a name="mips-sgi-irix5"></a>mips-sgi-irix5</h3>
1088
1089	<p>This configuration has considerable problems, which will be fixed in a
1090	future release.
1091
1092	<p>In order to compile GCC on an SGI running IRIX 5, the "compiler_dev.hdr"
1093	subsystem must be installed from the IDO CD-ROM supplied by Silicon
1094	Graphics. It is also available for download from
1095	<a href="http://www.sgi.com/developers/devtools/apis/ido.html">http://www.sgi.com/developers/devtools/apis/ido.html</a>.
1096
1097	<p><code>make compare</code> may fail on version 5 of IRIX unless you add
1098	<code>-save-temps</code> to <code>CFLAGS</code>. On these systems, the name of the
1099	assembler input file is stored in the object file, and that makes
1100	comparison fail if it differs between the <code>stage1</code> and
1101	<code>stage2</code> compilations. The option <code>-save-temps</code> forces a
1102	fixed name to be used for the assembler input file, instead of a
1103	randomly chosen name in <code>/tmp</code>. Do not add <code>-save-temps</code>
1104	unless the comparisons fail without that option. If you do you
1105	<code>-save-temps</code>, you will have to manually delete the <code>.i</code> and
1106	<code>.s</code> files after each series of compilations.
1107
1108	<p>If you use the MIPS C compiler to bootstrap, it may be necessary
1109	to increase its table size for switch statements with the
1110	<code>-Wf,-XNg1500</code> option. If you use the <code>-O2</code>
1111	optimization option, you also need to use <code>-Olimit 3000</code>.
1112
1113	<p>To enable debugging under IRIX 5, you must use GNU <code>as</code> 2.11.2
1114	or later,
1115	and use the <code>--with-gnu-as</code> configure option when configuring GCC.
1116	GNU <code>as</code> is distributed as part of the binutils package.
1117	When using release 2.11.2, you need to apply a patch
1118	<a href="http://sources.redhat.com/ml/binutils/2001-07/msg00352.html">http://sources.redhat.com/ml/binutils/2001-07/msg00352.html</a>
1119	which will be included in the next release of binutils.
1120
1121	<p>When building GCC, the build process loops rebuilding <code>cc1</code> over
1122	and over again. This happens on <code>mips-sgi-irix5.2</code>, and possibly
1123	other platforms. It has been reported that this is a known bug in the
1124	<code>make</code> shipped with IRIX 5.2. We recommend you use GNU
1125	<code>make</code> instead of the vendor supplied <code>make</code> program;
1126	however, you may have success with <code>smake</code> on IRIX 5.2 if you do
1127	not have GNU <code>make</code> available.
1128
1129	<hr />
1130
1131	<h3 class="heading"><a name="TOC42"></a><a name="mips-sgi-irix6"></a>mips-sgi-irix6</h3>
1132
1133	<p>If you are using IRIX <code>cc</code> as your bootstrap compiler, you must
1134	ensure that the N32 ABI is in use. To test this, compile a simple C
1135	file with <code>cc</code> and then run <code>file</code> on the
1136	resulting object file. The output should look like:
1137
1138	<pre class="example"> test.o: ELF N32 MSB ...
1139	</pre>
1140
1141	<p>If you see:
1142
1143	<pre class="example"> test.o: ELF 32-bit MSB ...
1144	</pre>
1145
1146	<p>or
1147
1148	<pre class="example"> test.o: ELF 64-bit MSB ...
1149	</pre>
1150
1151	<p>then your version of <code>cc</code> uses the O32 or N64 ABI by default. You
1152	should set the environment variable <code>CC</code> to <code>cc -n32</code>
1153	before configuring GCC.
1154
1155	<p>If you want the resulting <code>gcc</code> to run on old 32-bit systems
1156	with the MIPS R4400 CPU, you need to ensure that only code for the mips3
1157	instruction set architecture (ISA) is generated. While GCC 3.x does
1158	this correctly, both GCC 2.95 and SGI's MIPSpro <code>cc</code> may change
1159	the ISA depending on the machine where GCC is built. Using one of them
1160	as the bootstrap compiler may result in mips4 code, which won't run at
1161	all on mips3-only systems. For the test program above, you should see:
1162
1163	<pre class="example"> test.o: ELF N32 MSB mips-3 ...
1164	</pre>
1165
1166	<p>If you get:
1167
1168	<pre class="example"> test.o: ELF N32 MSB mips-4 ...
1169	</pre>
1170
1171	<p>instead, you should set the environment variable <code>CC</code> to <code>cc
1172	-n32 -mips3</code> or <code>gcc -mips3</code> respectively before configuring GCC.
1173
1174	<p>GCC on IRIX 6 is usually built to support both the N32 and N64 ABIs. If
1175	you build GCC on a system that doesn't have the N64 libraries installed,
1176	you need to configure with <code>--disable-multilib</code> so GCC doesn't
1177	try to use them. Look for <code>/usr/lib64/libc.so.1</code> to see if you
1178	have the 64-bit libraries installed.
1179
1180	<p>You must <em>not</em> use GNU <code>as</code> (which isn't built anyway as of
1181	binutils 2.11.2) on IRIX 6 platforms; doing so will only cause problems.
1182
1183	<p>GCC does not currently support generating O32 ABI binaries in the
1184	<code>mips-sgi-irix6</code> configurations. It is possible to create a GCC
1185	with O32 ABI only support by configuring it for the <code>mips-sgi-irix5</code>
1186	target and using a patched GNU <code>as</code> 2.11.2 as documented in the
1187	<a href="#mips-sgi-irix5"><code>mips-sgi-irix5</code></a> section above. Using the
1188	native assembler requires patches to GCC which will be included in a
1189	future release. It is
1190	expected that O32 ABI support will be available again in a future release.
1191
1192	<p>The <code>--enable-threads</code> option doesn't currently work, a patch is
1193	in preparation for a future release. The <code>--enable-libgcj</code>
1194	option is disabled by default: IRIX 6 uses a very low default limit
1195	(20480) for the command line length. Although libtool contains a
1196	workaround for this problem, at least the N64 <code>libgcj</code> is known not
1197	to build despite this, running into an internal error of the native
1198	<code>ld</code>. A sure fix is to increase this limit (<code>ncargs</code>) to
1199	its maximum of 262144 bytes. If you have root access, you can use the
1200	<code>systune</code> command to do this.
1201
1202	<p>GCC does not correctly pass/return structures which are
1203	smaller than 16 bytes and which are not 8 bytes. The problem is very
1204	involved and difficult to fix. It affects a number of other targets also,
1205	but IRIX 6 is affected the most, because it is a 64-bit target, and 4 byte
1206	structures are common. The exact problem is that structures are being padded
1207	at the wrong end, e.g. a 4 byte structure is loaded into the lower 4 bytes
1208	of the register when it should be loaded into the upper 4 bytes of the
1209	register.
1210
1211	<p>GCC is consistent with itself, but not consistent with the SGI C compiler
1212	(and the SGI supplied runtime libraries), so the only failures that can
1213	happen are when there are library functions that take/return such
1214	structures. There are very few such library functions. Currently this
1215	is known to affect <code>inet_ntoa</code>, <code>inet_lnaof</code>,
1216	<code>inet_netof</code>, <code>inet_makeaddr</code>, and <code>semctl</code>. Until the
1217	bug is fixed, GCC contains workarounds for the known affected functions.
1218
1219	<p>See <a href="http://freeware.sgi.com/">http://freeware.sgi.com/</a> for more
1220	information about using GCC on IRIX platforms.
1221
1222	<hr />
1223
1224	<h3 class="heading"><a name="TOC43"></a><a name="powerpc--"></a>powerpc--*</h3>
1225
1226	<p>You can specify a default version for the <code>-mcpu=</code><var>cpu_type</var><code></code>
1227	switch by using the configure option <code>--with-cpu-</code><var>cpu_type</var><code></code>.
1228
1229	<hr />
1230
1231	<h3 class="heading"><a name="TOC44"></a><a name="powerpc--darwin"></a>powerpc--darwin</h3>
1232
1233	<p>PowerPC running Darwin (Mac OS X kernel).
1234
1235	<p>Pre-installed versions of Mac OS X may not include any developer tools,
1236	meaning that you will not be able to build GCC from source. Tool
1237	binaries are available at
1238	<a href="http://developer.apple.com/tools/compilers.html">http://developer.apple.com/tools/compilers.html</a> (free
1239	registration required).
1240
1241	<p>The default stack limit of 512K is too small, which may cause compiles
1242	to fail with 'Bus error'. Set the stack larger, for instance
1243	by doing <code>limit stack 800</code>. It's a good idea to use the GNU
1244	preprocessor instead of Apple's <code>cpp-precomp</code> during the first stage of
1245	bootstrapping; this is automatic when doing <code>make bootstrap</code>, but
1246	to do it from the toplevel objdir you will need to say <code>make
1247	CC='cc -no-cpp-precomp' bootstrap</code>.
1248
1249	<p>The version of GCC shipped by Apple typically includes a number of
1250	extensions not available in a standard GCC release. These extensions
1251	are generally specific to Mac programming.
1252
1253	<hr />
1254
1255	<h3 class="heading"><a name="TOC45"></a><a name="powerpc--elf"></a>powerpc--elf, powerpc-*-sysv4</h3>
1256
1257	<p>PowerPC system in big endian mode, running System V.4.
1258
1259	<hr />
1260
1261	<h3 class="heading"><a name="TOC46"></a><a name="powerpc--linux-gnu"></a>powerpc--linux-gnu</h3>
1262
1263	<p>You will need
1264	<a href="ftp://ftp.kernel.org/pub/linux/devel/binutils">binutils 2.13.90.0.10</a>
1265	or newer for a working GCC.
1266
1267	<hr />
1268
1269	<h3 class="heading"><a name="TOC47"></a><a name="powerpc--netbsd"></a>powerpc--netbsd</h3>
1270
1271	<p>PowerPC system in big endian mode running NetBSD. To build the
1272	documentation you will need Texinfo version 4.2 (NetBSD 1.5.1 included
1273	Texinfo version 3.12).
1274
1275	<hr />
1276
1277	<h3 class="heading"><a name="TOC48"></a><a name="powerpc--eabiaix"></a>powerpc--eabiaix</h3>
1278
1279	<p>Embedded PowerPC system in big endian mode with <code>-mcall-aix</code> selected as
1280	the default.
1281
1282	<hr />
1283
1284	<h3 class="heading"><a name="TOC49"></a><a name="powerpc--eabisim"></a>powerpc--eabisim</h3>
1285
1286	<p>Embedded PowerPC system in big endian mode for use in running under the
1287	PSIM simulator.
1288
1289	<hr />
1290
1291	<h3 class="heading"><a name="TOC50"></a><a name="powerpc--eabi"></a>powerpc--eabi</h3>
1292
1293	<p>Embedded PowerPC system in big endian mode.
1294
1295	<hr />
1296
1297	<h3 class="heading"><a name="TOC51"></a><a name="powerpcle--elf"></a>powerpcle--elf, powerpcle-*-sysv4</h3>
1298
1299	<p>PowerPC system in little endian mode, running System V.4.
1300
1301	<hr />
1302
1303	<h3 class="heading"><a name="TOC52"></a><a name="powerpcle--eabisim"></a>powerpcle--eabisim</h3>
1304
1305	<p>Embedded PowerPC system in little endian mode for use in running under
1306	the PSIM simulator.
1307
1308	<hr />
1309
1310	<h3 class="heading"><a name="TOC53"></a><a name="powerpcle--eabi"></a>powerpcle--eabi</h3>
1311
1312	<p>Embedded PowerPC system in little endian mode.
1313
1314	<hr />
1315
1316	<h3 class="heading"><a name="TOC54"></a><a name="s390--linux"></a>s390--linux</h3>
1317
1318	<p>S/390 system running Linux for S/390.
1319
1320	<hr />
1321
1322	<h3 class="heading"><a name="TOC55"></a><a name="s390x--linux"></a>s390x--linux</h3>
1323
1324	<p>zSeries system (64-bit) running Linux for zSeries.
1325
1326	<hr />
1327
1328	<h3 class="heading"><a name="TOC56"></a><a name="--solaris2"></a>--solaris2</h3>
1329
1330	<p>Sun does not ship a C compiler with Solaris 2. To bootstrap and install
1331	GCC you first have to install a pre-built compiler, see our
1332	<a href="binaries.html">binaries page</a> for details.
1333
1334	<p>The Solaris 2 <code>/bin/sh</code> will often fail to configure
1335	<code>libstdc++-v3</code>, <code>boehm-gc</code> or <code>libjava</code>. We therefore
1336	recommend to use the following sequence of commands to bootstrap and
1337	install GCC:
1338
1339	<pre class="smallexample"> % CONFIG_SHELL=/bin/ksh
1340	% export CONFIG_SHELL
1341	% <var>srcdir</var>/configure [<var>options</var>] [<var>target</var>]
1342	% gmake bootstrap
1343	% gmake install
1344	</pre>
1345
1346	<p>As explained in the <a href="build.html">build</a> instructions, we recommend
1347	to use GNU make, which we call <code>gmake</code> here to distinguish it
1348	from Sun make.
1349
1350	<p>Solaris 2 comes with a number of optional OS packages. Some of these
1351	are needed to use GCC fully, namely <code>SUNWarc</code>,
1352	<code>SUNWbtool</code>, <code>SUNWesu</code>, <code>SUNWhea</code>, <code>SUNWlibm</code>,
1353	<code>SUNWsprot</code>, and <code>SUNWtoo</code>. If you did not install all
1354	optional packages when installing Solaris 2, you will need to verify that
1355	the packages that GCC needs are installed.
1356
1357	<p>To check whether an optional package is installed, use
1358	the <code>pkginfo</code> command. To add an optional package, use the
1359	<code>pkgadd</code> command. For further details, see the Solaris 2
1360	documentation.
1361
1362	<p>Trying to use the linker and other tools in
1363	<code>/usr/ucb</code> to install GCC has been observed to cause trouble.
1364	For example, the linker may hang indefinitely. The fix is to remove
1365	<code>/usr/ucb</code> from your <code>PATH</code>.
1366
1367	<p>The build process works more smoothly with the legacy Sun tools so, if you
1368	have <code>/usr/xpg4/bin</code> in your <code>PATH</code>, we recommend that you place
1369	<code>/usr/bin</code> before <code>/usr/xpg4/bin</code> for the duration of the build.
1370
1371	<p>All releases of GNU binutils prior to 2.11.2 have known bugs on this
1372	platform. We recommend the use of GNU binutils 2.11.2 or the vendor
1373	tools (Sun <code>as</code>, Sun <code>ld</code>).
1374
1375	<p>Sun bug 4296832 turns up when compiling X11 headers with GCC 2.95 or
1376	newer: <code>g++</code> will complain that types are missing. These headers assume
1377	that omitting the type means <code>int</code>; this assumption worked for C89 but
1378	is wrong for C++, and is now wrong for C99 also.
1379
1380	<p><code>g++</code> accepts such (invalid) constructs with the option
1381	<code>-fpermissive</code>; it
1382	will assume that any missing type is <code>int</code> (as defined by C89).
1383
1384	<p>There are patches for Solaris 2.6 (105633-56 or newer for SPARC,
1385	106248-42 or newer for Intel), Solaris 7 (108376-21 or newer for SPARC,
1386	108377-20 for Intel), and Solaris 8 (108652-24 or newer for SPARC,
1387	108653-22 for Intel) that fix this bug.
1388
1389	<hr />
1390
1391	<h3 class="heading"><a name="TOC57"></a><a name="sparc-sun-solaris2"></a>sparc-sun-solaris2</h3>
1392
1393	<p>When GCC is configured to use binutils 2.11.2 or later the binaries
1394	produced are smaller than the ones produced using Sun's native tools;
1395	this difference is quite significant for binaries containing debugging
1396	information.
1397
1398	<p>Sun <code>as</code> 4.x is broken in that it cannot cope with long symbol names.
1399	A typical error message might look similar to the following:
1400
1401	<pre class="smallexample"> /usr/ccs/bin/as: "/var/tmp/ccMsw135.s", line 11041: error:
1402	can't compute value of an expression involving an external symbol.
1403	</pre>
1404
1405	<p>This is Sun bug 4237974. This is fixed with patch 108908-02 for Solaris
1406	2.6 and has been fixed in later (5.x) versions of the assembler,
1407	starting with Solaris 7.
1408
1409	<p>Starting with Solaris 7, the operating system is capable of executing
1410	64-bit SPARC V9 binaries. GCC 3.1 and later properly supports
1411	this; the <code>-m64</code> option enables 64-bit code generation.
1412	However, if all you want is code tuned for the UltraSPARC CPU, you
1413	should try the <code>-mtune=ultrasparc</code> option instead, which produces
1414	code that, unlike full 64-bit code, can still run on non-UltraSPARC
1415	machines.
1416
1417	<p>When configuring on a Solaris 7 or later system that is running a kernel
1418	that supports only 32-bit binaries, one must configure with
1419	<code>--disable-multilib</code>, since we will not be able to build the
1420	64-bit target libraries.
1421
1422	<p>GCC 3.3 triggers code generation bugs in earlier versions of the GNU
1423	compiler (especially GCC 3.0.x versions), which lead to the miscompilation
1424	of the stage1 compiler and the subsequent failure of the bootstrap process.
1425	A workaround is to use GCC 3.2.3 as an intermediary stage, i.e. to bootstrap
1426	that compiler with the base compiler and then use it to bootstrap the final
1427	compiler.
1428
1429	<hr />
1430
1431	<h3 class="heading"><a name="TOC58"></a><a name="sparc-sun-solaris2.7"></a>sparc-sun-solaris2.7</h3>
1432
1433	<p>Sun patch 107058-01 (1999-01-13) for Solaris 7/SPARC triggers a bug in
1434	the dynamic linker. This problem (Sun bug 4210064) affects GCC 2.8
1435	and later, including all EGCS releases. Sun formerly recommended
1436	107058-01 for all Solaris 7 users, but around 1999-09-01 it started to
1437	recommend it only for people who use Sun's compilers.
1438
1439	<p>Here are some workarounds to this problem:
1440	<ul>
1441	<li>Do not install Sun patch 107058-01 until after Sun releases a
1442	complete patch for bug 4210064. This is the simplest course to take,
1443	unless you must also use Sun's C compiler. Unfortunately 107058-01
1444	is preinstalled on some new Solaris 7-based hosts, so you may have to
1445	back it out.
1446
1447	<li>Copy the original, unpatched Solaris 7
1448	<code>/usr/ccs/bin/as</code> into
1449	<code>/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/3.1/as</code>,
1450	adjusting the latter name to fit your local conventions and software
1451	version numbers.
1452
1453	<li>Install Sun patch 106950-03 (1999-05-25) or later. Nobody with
1454	both 107058-01 and 106950-03 installed has reported the bug with GCC
1455	and Sun's dynamic linker. This last course of action is riskiest,
1456	for two reasons. First, you must install 106950 on all hosts that
1457	run code generated by GCC; it doesn't suffice to install it only on
1458	the hosts that run GCC itself. Second, Sun says that 106950-03 is
1459	only a partial fix for bug 4210064, but Sun doesn't know whether the
1460	partial fix is adequate for GCC. Revision -08 or later should fix
1461	the bug. The current (as of 2001-09-24) revision is -14, and is included in
1462	the Solaris 7 Recommended Patch Cluster.
1463	</ul>
1464
1465	<p>GCC 3.3 triggers a bug in version 5.0 Alpha 03/27/98 of the Sun assembler,
1466	which causes a bootstrap failure when linking the 64-bit shared version of
1467	libgcc. A typical error message is:
1468
1469	<pre class="smallexample"> ld: fatal: relocation error: R_SPARC_32: file libgcc/sparcv9/_muldi3.o:
1470	symbol <unknown>: offset 0xffffffff7ec133e7 is non-aligned.
1471	</pre>
1472
1473	<p>This bug has been fixed in the final 5.0 version of the assembler.
1474
1475	<p>
1476	<hr />
1477
1478	<h3 class="heading"><a name="TOC59"></a><a name="sparc-sun-sunos4"></a>sparc-sun-sunos4</h3>
1479
1480	<p>Support for this system is obsoleted in GCC 3.3.
1481
1482	<p>A bug in the SunOS 4 linker will cause it to crash when linking
1483	<code>-fPIC</code> compiled objects (and will therefore not allow you to build
1484	shared libraries).
1485
1486	<p>To fix this problem you can either use the most recent version of
1487	binutils or get the latest SunOS 4 linker patch (patch ID 100170-10)
1488	from Sun's patch site.
1489
1490	<p>Sometimes on a Sun 4 you may observe a crash in the program
1491	<code>genflags</code> or <code>genoutput</code> while building GCC. This is said to
1492	be due to a bug in <code>sh</code>. You can probably get around it by running
1493	<code>genflags</code> or <code>genoutput</code> manually and then retrying the
1494	<code>make</code>.
1495
1496	<hr />
1497
1498	<h3 class="heading"><a name="TOC60"></a><a name="sparc-unknown-linux-gnulibc1"></a>sparc-unknown-linux-gnulibc1</h3>
1499
1500	<p>Support for this system is obsoleted in GCC 3.3.
1501
1502	<p>It has been reported that you might need
1503	<a href="ftp://ftp.yggdrasil.com/private/hjl">binutils 2.8.1.0.23</a>
1504	for this platform, too.
1505
1506	<hr />
1507
1508	<h3 class="heading"><a name="TOC61"></a><a name="sparc--linux"></a>sparc--linux</h3>
1509
1510	<p>GCC versions 3.0 and higher require binutils 2.11.2 and glibc 2.2.4
1511	or newer on this platform. All earlier binutils and glibc
1512	releases mishandled unaligned relocations on <code>sparc--</code> targets.
1513
1514	<hr />
1515
1516	<h3 class="heading"><a name="TOC62"></a><a name="sparc64--solaris2"></a>sparc64--solaris2</h3>
1517
1518	<p>The following compiler flags must be specified in the configure
1519	step in order to bootstrap this target with the Sun compiler:
1520
1521	<pre class="example"> % CC="cc -xildoff -xarch=v9" <var>srcdir</var>/configure [<var>options</var>] [<var>target</var>]
1522	</pre>
1523
1524	<p><code>-xildoff</code> turns off the incremental linker, and <code>-xarch=v9</code>
1525	specifies the SPARC-V9 architecture to the Sun linker and assembler.
1526
1527	<hr />
1528
1529	<h3 class="heading"><a name="TOC63"></a><a name="sparcv9--solaris2"></a>sparcv9--solaris2</h3>
1530
1531	<p>This is a synonym for sparc64--solaris2.
1532
1533	<hr />
1534
1535	<h3 class="heading"><a name="TOC64"></a><a name="%23--sysv"></a>--sysv</h3>
1536
1537	<p>On System V release 3, you may get this error message
1538	while linking:
1539
1540	<pre class="smallexample"> ld fatal: failed to write symbol name <var>something</var>
1541	in strings table for file <var>whatever</var>
1542	</pre>
1543
1544	<p>This probably indicates that the disk is full or your ulimit won't allow
1545	the file to be as large as it needs to be.
1546
1547	<p>This problem can also result because the kernel parameter <code>MAXUMEM</code>
1548	is too small. If so, you must regenerate the kernel and make the value
1549	much larger. The default value is reported to be 1024; a value of 32768
1550	is said to work. Smaller values may also work.
1551
1552	<p>On System V, if you get an error like this,
1553
1554	<pre class="example"> /usr/local/lib/bison.simple: In function `yyparse':
1555	/usr/local/lib/bison.simple:625: virtual memory exhausted
1556	</pre>
1557
1558	<p>that too indicates a problem with disk space, ulimit, or <code>MAXUMEM</code>.
1559
1560	<p>On a System V release 4 system, make sure <code>/usr/bin</code> precedes
1561	<code>/usr/ucb</code> in <code>PATH</code>. The <code>cc</code> command in
1562	<code>/usr/ucb</code> uses libraries which have bugs.
1563
1564	<hr />
1565
1566	<h3 class="heading"><a name="TOC65"></a><a name="vax-dec-ultrix"></a>vax-dec-ultrix</h3>
1567
1568	<p>Don't try compiling with VAX C (<code>vcc</code>). It produces incorrect code
1569	in some cases (for example, when <code>alloca</code> is used).
1570
1571	<hr />
1572
1573	<h3 class="heading"><a name="TOC66"></a><a name="x86_64--"></a>x86_64--, amd64--</h3>
1574
1575	<p>GCC supports the x86-64 architecture implemented by the AMD64 processor
1576	(amd64-- is an alias for x86_64--) on GNU/Linux, FreeBSD and NetBSD.
1577	On GNU/Linux the default is a bi-arch compiler which is able to generate
1578	both 64-bit x86-64 and 32-bit x86 code (via the <code>-m32</code> switch).
1579
1580	<hr />
1581
1582	<h3 class="heading"><a name="TOC67"></a><a name="xtensa--elf"></a>xtensa--elf</h3>
1583
1584	<p>This target is intended for embedded Xtensa systems using the
1585	<code>newlib</code> C library. It uses ELF but does not support shared
1586	objects. Designed-defined instructions specified via the
1587	Tensilica Instruction Extension (TIE) language are only supported
1588	through inline assembly.
1589
1590	<p>The Xtensa configuration information must be specified prior to
1591	building GCC. The <code>gcc/config/xtensa/xtensa-config.h</code> header
1592	file contains the configuration information. If you created your
1593	own Xtensa configuration with the Xtensa Processor Generator, the
1594	downloaded files include a customized copy of this header file,
1595	which you can use to replace the default header file.
1596
1597	<hr />
1598
1599	<h3 class="heading"><a name="TOC68"></a><a name="xtensa--linux"></a>xtensa--linux</h3>
1600
1601	<p>This target is for Xtensa systems running GNU/Linux. It supports ELF
1602	shared objects and the GNU C library (glibc). It also generates
1603	position-independent code (PIC) regardless of whether the
1604	<code>-fpic</code> or <code>-fPIC</code> options are used. In other
1605	respects, this target is the same as the
1606	<a href="#xtensa--elf"><code>xtensa--elf</code></a> target.
1607
1608	<hr />
1609
1610	<h3 class="heading"><a name="TOC69"></a><a name="windows"></a>Microsoft Windows (32-bit)</h3>
1611
1612	<p>A port of GCC 2.95.2 and 3.x is included with the
1613	<a href="http://www.cygwin.com/">Cygwin environment</a>.
1614
1615	<p>Current (as of early 2001) snapshots of GCC will build under Cygwin
1616	without modification.
1617
1618	<p>GCC does not currently build with Microsoft's C++ compiler and there
1619	are no plans to make it do so.
1620
1621	<hr />
1622
1623	<h3 class="heading"><a name="TOC70"></a><a name="os2"></a>OS/2</h3>
1624
1625	<p>GCC does not currently support OS/2. However, Andrew Zabolotny has been
1626	working on a generic OS/2 port with pgcc. The current code can be found
1627	at <a href="http://www.goof.com/pcg/os2/">http://www.goof.com/pcg/os2/</a>.
1628
1629	<p>An older copy of GCC 2.8.1 is included with the EMX tools available at
1630	<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>.
1631
1632	<hr />
1633
1634	<h3 class="heading"><a name="TOC71"></a><a name="older"></a>Older systems</h3>
1635
1636	<p>GCC contains support files for many older (1980s and early
1637	1990s) Unix variants. For the most part, support for these systems
1638	has not been deliberately removed, but it has not been maintained for
1639	several years and may suffer from bitrot.
1640
1641	<p>Starting with GCC 3.1, each release has a list of "obsoleted" systems.
1642	Support for these systems is still present in that release, but
1643	<code>configure</code> will fail unless the <code>--enable-obsolete</code>
1644	option is given. Unless a maintainer steps forward, support for these
1645	systems will be removed from the next release of GCC.
1646
1647	<p>Support for old systems as hosts for GCC can cause problems if the
1648	workarounds for compiler, library and operating system bugs affect the
1649	cleanliness or maintainability of the rest of GCC. In some cases, to
1650	bring GCC up on such a system, if still possible with current GCC, may
1651	require first installing an old version of GCC which did work on that
1652	system, and using it to compile a more recent GCC, to avoid bugs in the
1653	vendor compiler. Old releases of GCC 1 and GCC 2 are available in the
1654	<code>old-releases</code> directory on the <a href="../mirrors.html">GCC mirror sites</a>. Header bugs may generally be avoided using
1655	<code>fixincludes</code>, but bugs or deficiencies in libraries and the
1656	operating system may still cause problems.
1657
1658	<p>Support for older systems as targets for cross-compilation is less
1659	problematic than support for them as hosts for GCC; if an enthusiast
1660	wishes to make such a target work again (including resurrecting any of
1661	the targets that never worked with GCC 2, starting from the last CVS
1662	version before they were removed), patches
1663	<a href="../contribute.html">following the usual requirements</a> would be
1664	likely to be accepted, since they should not affect the support for more
1665	modern targets.
1666
1667	<p>For some systems, old versions of GNU binutils may also be useful,
1668	and are available from <code>pub/binutils/old-releases</code> on
1669	<a href="http://sources.redhat.com/mirrors.html">sources.redhat.com mirror sites</a>.
1670
1671	<p>Some of the information on specific systems above relates to
1672	such older systems, but much of the information
1673	about GCC on such systems (which may no longer be applicable to
1674	current GCC) is to be found in the GCC texinfo manual.
1675
1676	<hr />
1677
1678	<h3 class="heading"><a name="TOC72"></a><a name="elf_targets"></a>all ELF targets (SVR4, Solaris 2, etc.)</h3>
1679
1680	<p>C++ support is significantly better on ELF targets if you use the
1681	<a href="./configure.html#with-gnu-ld">GNU linker</a>; duplicate copies of
1682	inlines, vtables and template instantiations will be discarded
1683	automatically.
1684
1685	<hr />
1686	<p>
1687	<a href="./index.html">Return to the GCC Installation page</a>
1688
1689	</body></html>
1690

Note: See TracBrowser for help on using the repository browser.

Download in other formats: