Context Navigation

specific.html@ 2013

Visit:

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

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

Context Navigation

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

Download in other formats: