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

Last change on this file since 628 was 2, checked in by bird, 23 years ago

Initial revision
  • Property cvs2svn:cvs-rev set to 1.1
  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 86.5 KB
Line 
1<html lang="en"><head>
2<title>Host/Target specific installation notes for GCC</title>
3<meta http-equiv="Content-Type" content="text/html">
4<meta name=description content="Host/Target specific installation notes for GCC">
5<meta name=generator content="makeinfo 4.0">
6<link href="http://texinfo.org/" rel=generator-home>
7</head><body>
8
9<p>P<p>lease read this document carefully <em>before</em> installing the
10GNU Compiler Collection on your machine.
11
12<ul>
13<li><a href="#1750a-*-*">1750a-*-*</a>
14<li><a href="#a29k">a29k</a>
15<li><a href="#a29k-*-bsd">a29k-*-bsd</a>
16<li><a href="#alpha*-*-*">alpha*-*-*</a>
17<li><a href="#alpha*-dec-osf*">alpha*-dec-osf*</a>
18<li><a href="#alphaev5-cray-unicosmk*">alphaev5-cray-unicosmk*</a>
19<li><a href="#arc-*-elf">arc-*-elf</a>
20<li><a href="#arm-*-aout">arm-*-aout</a>
21<li><a href="#arm-*-elf">arm-*-elf</a>
22<li><a href="#arm*-*-linux-gnu">arm*-*-linux-gnu</a>
23<li><a href="#arm-*-riscix">arm-*-riscix</a>
24<li><a href="#avr">avr</a>
25<li><a href="#c4x">c4x</a>
26<li><a href="#dos">DOS</a>
27<li><a href="#dsp16xx">dsp16xx</a>
28<li><a href="#elxsi-elxsi-bsd">elxsi-elxsi-bsd</a>
29<li><a href="#*-*-freebsd*">*-*-freebsd*</a>
30<li><a href="#h8300-hms">h8300-hms</a>
31<li><a href="#hppa*-hp-hpux*">hppa*-hp-hpux*</a>
32<li><a href="#hppa*-hp-hpux9">hppa*-hp-hpux9</a>
33<li><a href="#hppa*-hp-hpux10">hppa*-hp-hpux10</a>
34<li><a href="#hppa*-hp-hpux11">hppa*-hp-hpux11</a>
35<li><a href="#i370-*-*">i370-*-*</a>
36<li><a href="#*-*-linux-gnu">*-*-linux-gnu</a>
37<li><a href="#ix86-*-linux*oldld">i?86-*-linux*oldld</a>
38<li><a href="#ix86-*-linux*aout">i?86-*-linux*aout</a>
39<li><a href="#ix86-*-linux*">i?86-*-linux*</a>
40<li><a href="#ix86-*-sco">i?86-*-sco</a>
41<li><a href="#ix86-*-sco3.2v4">i?86-*-sco3.2v4</a>
42<li><a href="#ix86-*-sco3.2v5*">i?86-*-sco3.2v5*</a>
43<li><a href="#ix86-*-udk">i?86-*-udk</a>
44<li><a href="#ix86-*-isc">i?86-*-isc</a>
45<li><a href="#ix86-*-esix">i?86-*-esix</a>
46<li><a href="#ix86-ibm-aix">i?86-ibm-aix</a>
47<li><a href="#ix86-sequent-bsd">i?86-sequent-bsd</a>
48<li><a href="#ix86-sequent-ptx1*">i?86-sequent-ptx1*</a> i?86-sequent-ptx2*, i?86-sequent-sysv3*
49<li><a href="#i860-intel-osf*">i860-intel-osf*</a>
50<li><a href="#ia64-*-linux">ia64-*-linux</a>
51<li><a href="#*-lynx-lynxos">*-lynx-lynxos</a>
52<li><a href="#*-ibm-aix*">*-ibm-aix*</a>
53<li><a href="#m32r-*-elf">m32r-*-elf</a>
54<li><a href="#m68000-hp-bsd">m68000-hp-bsd</a>
55<li><a href="#m6811-elf">m6811-elf</a>
56<li><a href="#m6812-elf">m6812-elf</a>
57<li><a href="#m68k-altos">m68k-altos</a>
58<li><a href="#m68k-apple-aux">m68k-apple-aux</a>
59<li><a href="#m68k-att-sysv">m68k-att-sysv</a>
60<li><a href="#m68k-bull-sysv">m68k-bull-sysv</a>
61<li><a href="#m68k-crds-unos">m68k-crds-unos</a>
62<li><a href="#m68k-hp-hpux">m68k-hp-hpux</a>
63<li><a href="#m68k-*-nextstep*">m68k-*-nextstep*</a>
64<li><a href="#m68k-ncr-*">m68k-ncr-*</a>
65<li><a href="#m68k-sun">m68k-sun</a>
66<li><a href="#m68k-sun-sunos4.1.1">m68k-sun-sunos4.1.1</a>
67<li><a href="#m88k-*-svr3">m88k-*-svr3</a>
68<li><a href="#m88k-*-dgux">m88k-*-dgux</a>
69<li><a href="#m88k-tektronix-sysv3">m88k-tektronix-sysv3</a>
70<li><a href="#mips-*-*">mips-*-*</a>
71<li><a href="#mips-dec-*">mips-dec-*</a>
72<li><a href="#mips-mips-bsd">mips-mips-bsd</a>
73<li><a href="#mips-mips-riscos*">mips-mips-riscos*</a>
74<li><a href="#mips-sgi-irix4">mips-sgi-irix4</a>
75<li><a href="#mips-sgi-irix5">mips-sgi-irix5</a>
76<li><a href="#mips-sgi-irix6">mips-sgi-irix6</a>
77<li><a href="#mips-sony-sysv">mips-sony-sysv</a>
78<li><a href="#ns32k-encore">ns32k-encore</a>
79<li><a href="#ns32k-*-genix">ns32k-*-genix</a>
80<li><a href="#ns32k-sequent">ns32k-sequent</a>
81<li><a href="#ns32k-utek">ns32k-utek</a>
82<li><a href="#powerpc*-*-*">powerpc*-*-*</a> powerpc-*-sysv4
83<li><a href="#powerpc-*-darwin*">powerpc-*-darwin*</a>
84<li><a href="#powerpc-*-elf">powerpc-*-elf</a> powerpc-*-sysv4
85<li><a href="#powerpc-*-linux-gnu*">powerpc-*-linux-gnu*</a>
86<li><a href="#powerpc-*-netbsd*">powerpc-*-netbsd*</a>
87<li><a href="#powerpc-*-eabiaix">powerpc-*-eabiaix</a>
88<li><a href="#powerpc-*-eabisim">powerpc-*-eabisim</a>
89<li><a href="#powerpc-*-eabi">powerpc-*-eabi</a>
90<li><a href="#powerpcle-*-elf">powerpcle-*-elf</a> powerpcle-*-sysv4
91<li><a href="#powerpcle-*-eabisim">powerpcle-*-eabisim</a>
92<li><a href="#powerpcle-*-eabi">powerpcle-*-eabi</a>
93<li><a href="#powerpcle-*-winnt">powerpcle-*-winnt</a> powerpcle-*-pe
94<li><a href="#romp-*-aos">romp-*-aos</a> romp-*-mach
95<li><a href="#s390-*-linux*">#s390-*-linux*</a>
96<li><a href="#s390x-*-linux*">#s390x-*-linux*</a>
97<li><a href="#*-*-solaris2*">*-*-solaris2*</a>
98<li><a href="#sparc-sun-solaris2*">sparc-sun-solaris2*</a>
99<li><a href="#sparc-sun-solaris2.7">sparc-sun-solaris2.7</a>
100<li><a href="#sparc-sun-sunos4*">sparc-sun-sunos4*</a>
101<li><a href="#sparc-unknown-linux-gnulibc1">sparc-unknown-linux-gnulibc1</a>
102<li><a href="#sparc-*-linux*">sparc-*-linux*</a>
103<li><a href="#sparc64-*-*">sparc64-*-*</a>
104<li><a href="#sparcv9-*-solaris2*">sparcv9-*-solaris2*</a>
105<li><a href="#*-*-sysv*">*-*-sysv*</a>
106<li><a href="#vax-dec-ultrix">vax-dec-ultrix</a>
107<li><a href="#we32k-*-*">we32k-*-*</a>
108<li><a href="#xtensa-*-elf">xtensa-*-elf</a>
109<li><a href="#xtensa-*-linux*">xtensa-*-linux*</a>
110<li><a href="#windows">Microsoft Windows</a>
111<li><a href="#os2">OS/2</a>
112<li><a href="#older">Older systems</a>
113</ul>
114
115<ul>
116<li><a href="#elf_targets">all ELF targets</a> (SVR4, Solaris 2, etc.)
117</ul>
118
119<!- ------- host/target specific issues start here --------------- ->
120<hr />
121
122<h2><a name="TOC0"><a name="1750a-*-*"></a>1750a-*-*</h2>
123
124<p>MIL-STD-1750A processors. This target is obsoleted in GCC 3.1.
125
126<p>The MIL-STD-1750A cross configuration produces output for
127<code>as1750</code>, an assembler/linker available under the GNU General Public
128License for the 1750A. <code>as1750</code> can be obtained at
129<a href="ftp://ftp.fta-berlin.de/pub/crossgcc/1750gals/">ftp://ftp.fta-berlin.de/pub/crossgcc/1750gals/</a>.
130A similarly licensed simulator for
131the 1750A is available from same address.
132
133<p>You should ignore a fatal error during the building of <code>libgcc</code>
134(<code>libgcc</code> is not yet implemented for the 1750A.)
135
136<p>The <code>as1750</code> assembler requires the file <code>ms1750.inc</code>, which is
137found in the directory <code>gcc/config/1750a</code>.
138
139<p>GCC produced the same sections as the Fairchild F9450 C Compiler,
140namely:
141
142<dl>
143<dt><code>Normal</code>
144<dd>The program code section.
145
146<br><dt><code>Static</code>
147<dd>The read/write (RAM) data section.
148
149<br><dt><code>Konst</code>
150<dd>The read-only (ROM) constants section.
151
152<br><dt><code>Init</code>
153<dd>Initialization section (code to copy KREL to SREL).
154</dl>
155
156<p>The smallest addressable unit is 16 bits (<code>BITS_PER_UNIT</code> is 16). This
157means that type <code>char</code> is represented with a 16-bit word per character.
158The 1750A's "Load/Store Upper/Lower Byte" instructions are not used by
159GCC.
160
161<hr />
162
163<h2><a name="TOC1"><a name="a29k"></a>a29k</h2>
164
165<p>AMD Am29k-family processors. These are normally used in embedded
166applications. This configuration corresponds to AMD's standard calling
167sequence and binary interface and is compatible with other 29k tools.
168
169<p>AMD has abandoned this processor. All existing a29k targets are obsoleted
170in GCC 3.1.
171
172<p>You may need to make a variant of the file <code>a29k.h</code> for your
173particular configuration.
174
175<hr />
176
177<h2><a name="TOC2"><a name="a29k-*-bsd"></a>a29k-*-bsd</h2>
178
179<p>AMD Am29050 used in a system running a variant of BSD Unix.
180
181<hr />
182
183<h2><a name="TOC3"><a name="alpha*-*-*"></a>alpha*-*-*</h2>
184
185<p>This section contains general configuration information for all
186alpha-based platforms using ELF (in particular, ignore this section for
187DEC OSF/1, Digital UNIX and Tru64 UNIX). In addition to reading this
188section, please read all other sections that match your target.
189
190<p>We require binutils 2.11.2 or newer.
191Previous binutils releases had a number of problems with DWARF 2
192debugging information, not the least of which is incorrect linking of
193shared libraries.
194
195<hr />
196
197<h2><a name="TOC4"><a name="alpha*-dec-osf*"></a>alpha*-dec-osf*</h2>
198
199<p>Systems using processors that implement the DEC Alpha architecture and
200are running the DEC/Compaq Unix (DEC OSF/1, Digital UNIX, or Compaq
201Tru64 UNIX) operating system, for example the DEC Alpha AXP systems.
202
203<p>Support for versions before <code>alpha*-dec-osf4</code> is obsoleted in GCC
2043.1. (These are the versions which identify themselves as DEC OSF/1.)
205
206<p>In Digital Unix V4.0, virtual memory exhausted bootstrap failures
207may be fixed by configuring with <code>--with-gc=simple</code>,
208reconfiguring Kernel Virtual Memory and Swap parameters
209per the <code>/usr/sbin/sys_check</code> Tuning Suggestions,
210or applying the patch in
211<a href="http://gcc.gnu.org/ml/gcc/2002-08/msg00822.html">http://gcc.gnu.org/ml/gcc/2002-08/msg00822.html</a>.
212
213<p>In Tru64 UNIX V5.1, Compaq introduced a new assembler that does not
214currently (2001-06-13) work with <code>mips-tfile</code>. As a workaround,
215we need to use the old assembler, invoked via the barely documented
216<code>-oldas</code> option. To bootstrap GCC, you either need to use the
217Compaq C Compiler:
218
219<pre> % CC=cc <var>srcdir</var>/configure [<var>options</var>] [<var>target</var>]
220</pre>
221
222<p>or you can use a copy of GCC 2.95.3 or higher built on Tru64 UNIX V4.0:
223
224<pre> % CC=gcc -Wa,-oldas <var>srcdir</var>/configure [<var>options</var>] [<var>target</var>]
225</pre>
226
227<p>As of GNU binutils 2.11.2, neither GNU <code>as</code> nor GNU <code>ld</code>
228are supported on Tru64 UNIX, so you must not configure GCC with
229<code>--with-gnu-as</code> or <code>--with-gnu-ld</code>.
230
231<p>The <code>--enable-threads</code> options isn't supported yet. A patch is
232in preparation for a future release.
233
234<p>GCC writes a <code>.verstamp</code> directive to the assembler output file
235unless it is built as a cross-compiler. It gets the version to use from
236the system header file <code>/usr/include/stamp.h</code>. If you install a
237new version of DEC Unix, you should rebuild GCC to pick up the new version
238stamp.
239
240<p>Note that since the Alpha is a 64-bit architecture, cross-compilers from
24132-bit machines will not generate code as efficient as that generated
242when the compiler is running on a 64-bit machine because many
243optimizations that depend on being able to represent a word on the
244target in an integral value on the host cannot be performed. Building
245cross-compilers on the Alpha for 32-bit machines has only been tested in
246a few cases and may not work properly.
247
248<p><code>make compare</code> may fail on old versions of DEC Unix unless you add
249<code>-save-temps</code> to <code>CFLAGS</code>. On these systems, the name of the
250assembler input file is stored in the object file, and that makes
251comparison fail if it differs between the <code>stage1</code> and
252<code>stage2</code> compilations. The option <code>-save-temps</code> forces a
253fixed name to be used for the assembler input file, instead of a
254randomly chosen name in <code>/tmp</code>. Do not add <code>-save-temps</code>
255unless the comparisons fail without that option. If you add
256<code>-save-temps</code>, you will have to manually delete the <code>.i</code> and
257<code>.s</code> files after each series of compilations.
258
259<p>GCC now supports both the native (ECOFF) debugging format used by DBX
260and GDB and an encapsulated STABS format for use only with GDB. See the
261discussion of the <code>--with-stabs</code> option of <code>configure</code> above
262for more information on these formats and how to select them.
263
264<p>There is a bug in DEC's assembler that produces incorrect line numbers
265for ECOFF format when the <code>.align</code> directive is used. To work
266around this problem, GCC will not emit such alignment directives
267while writing ECOFF format debugging information even if optimization is
268being performed. Unfortunately, this has the very undesirable
269side-effect that code addresses when <code>-O</code> is specified are
270different depending on whether or not <code>-g</code> is also specified.
271
272<p>To avoid this behavior, specify <code>-gstabs+</code> and use GDB instead of
273DBX. DEC is now aware of this problem with the assembler and hopes to
274provide a fix shortly.
275
276<hr />
277
278<h2><a name="TOC5"><a name="alphaev5-cray-unicosmk*"></a>alphaev5-cray-unicosmk*</h2>
279
280<p>Cray T3E systems running Unicos/Mk.
281
282<p>This port is incomplete and has many known bugs. We hope to improve the
283support for this target soon. Currently, only the C front end is supported,
284and it is not possible to build parallel applications. Cray modules are not
285supported; in particular, Craylibs are assumed to be in
286<code>/opt/ctl/craylibs/craylibs</code>.
287
288<p>You absolutely <strong>must</strong> use GNU make on this platform. Also, you
289need to tell GCC where to find the assembler and the linker. The
290simplest way to do so is by providing <code>--with-as</code> and
291<code>--with-ld</code> to <code>configure</code>, e.g.
292
293<pre> configure --with-as=/opt/ctl/bin/cam --with-ld=/opt/ctl/bin/cld \
294 --enable-languages=c
295</pre>
296
297<p>The comparison test during <code>make bootstrap</code> fails on Unicos/Mk
298because the assembler inserts timestamps into object files. You should
299be able to work around this by doing <code>make all</code> after getting this
300failure.
301
302<hr />
303
304<h2><a name="TOC6"><a name="arc-*-elf"></a>arc-*-elf</h2>
305
306<p>Argonaut ARC processor.
307This configuration is intended for embedded systems.
308
309<hr />
310
311<h2><a name="TOC7"><a name="arm-*-aout"></a>arm-*-aout</h2>
312
313<p>Advanced RISC Machines ARM-family processors. These are often used in
314embedded applications. There are no standard Unix configurations.
315This configuration corresponds to the basic instruction sequences and will
316produce <code>a.out</code> format object modules.
317
318<p>You may need to make a variant of the file <code>arm.h</code> for your particular
319configuration.
320
321<hr />
322
323<h2><a name="TOC8"><a name="arm-*-elf"></a>arm-*-elf</h2>
324
325<p>This configuration is intended for embedded systems.
326
327<hr />
328
329<h2><a name="TOC9"><a name="arm*-*-linux-gnu"></a>arm*-*-linux-gnu</h2>
330
331<p>We require GNU binutils 2.10 or newer.
332
333<hr />
334
335<h2><a name="TOC10"><a name="arm-*-riscix"></a>arm-*-riscix</h2>
336
337<p>The ARM2 or ARM3 processor running RISC iX, Acorn's port of BSD Unix.
338This configuration is obsoleted in GCC 3.1.
339
340<p>If you are running a version of RISC iX prior to 1.2 then you must
341specify the version number during configuration. Note that the
342assembler shipped with RISC iX does not support stabs debugging
343information; a new version of the assembler, with stabs support
344included, is now available from Acorn and via ftp
345<a href="ftp://ftp.acorn.com/pub/riscix/as+xterm.tar.Z">ftp://ftp.acorn.com/pub/riscix/as+xterm.tar.Z</a>. To enable stabs
346debugging, pass <code>--with-gnu-as</code> to configure.
347
348<p>You will need to install GNU <code>sed</code> before you can run configure.
349
350<hr />
351
352<h2><a name="TOC11"><a name="avr"></a>avr</h2>
353
354<p>ATMEL AVR-family micro controllers. These are used in embedded
355applications. There are no standard Unix configurations.
356See "AVR Options" in the main manual
357for the list of supported MCU types.
358
359<p>Use <code>configure --target=avr --enable-languages="c"</code> to configure GCC.
360
361<p>Further installation notes and other useful information about AVR tools
362can also be obtained from:
363
364<ul>
365<li><a href="http://home.overta.ru/users/denisc">http://home.overta.ru/users/denisc</a>
366<li><a href="http://www.amelek.gda.pl/avr">http://www.amelek.gda.pl/avr</a>
367</ul>
368
369<p>We <em>strongly</em> recommend using binutils 2.11 or newer.
370
371<p>The following error:
372<pre> Error: register required
373</pre>
374
375<p>indicates that you should upgrade to a newer version of the binutils.
376
377<hr />
378
379<h2><a name="TOC12"><a name="c4x"></a>c4x</h2>
380
381<p>Texas Instruments TMS320C3x and TMS320C4x Floating Point Digital Signal
382Processors. These are used in embedded applications. There are no
383standard Unix configurations.
384See "TMS320C3x/C4x Options" in the main manual
385for the list of supported MCU types.
386
387<p>GCC can be configured as a cross compiler for both the C3x and C4x
388architectures on the same system. Use <code>configure --target=c4x
389--enable-languages="c,c++"</code> to configure.
390
391<p>Further installation notes and other useful information about C4x tools
392can also be obtained from:
393
394<ul>
395<li><a href="http://www.elec.canterbury.ac.nz/c4x/">http://www.elec.canterbury.ac.nz/c4x/</a>
396</ul>
397
398<hr />
399
400<h2><a name="TOC13"><a name="cris"></a>CRIS</h2>
401
402<p>CRIS is the CPU architecture in Axis Communications ETRAX system-on-a-chip
403series. These are used in embedded applications.
404
405<p>See "CRIS Options" in the main manual
406for a list of CRIS-specific options.
407
408<p>There are a few different CRIS targets:
409<dl>
410<dt><code>cris-axis-aout</code>
411<dd>Old target. Includes a multilib for the <code>elinux</code> a.out-based
412target. No multilibs for newer architecture variants.
413<br><dt><code>cris-axis-elf</code>
414<dd>Mainly for monolithic embedded systems. Includes a multilib for the
415<code>v10</code> core used in <code>ETRAX 100 LX</code>.
416<br><dt><code>cris-axis-linux-gnu</code>
417<dd>A GNU/Linux port for the CRIS architecture, currently targeting
418<code>ETRAX 100 LX</code> by default.
419</dl>
420
421<p>For <code>cris-axis-aout</code> and <code>cris-axis-elf</code> you need binutils 2.11
422or newer. For <code>cris-axis-linux-gnu</code> you need binutils 2.12 or newer.
423
424<p>Pre-packaged tools can be obtained from
425<a href="ftp://ftp.axis.com/pub/axis/tools/cris/compiler-kit/">ftp://ftp.axis.com/pub/axis/tools/cris/compiler-kit/</a>. More
426information about this platform is available at
427<a href="http://developer.axis.com/">http://developer.axis.com/</a>.
428
429<hr />
430
431<h2><a name="TOC14"><a name="dos"></a>DOS</h2>
432
433<p>Please have a look at our <a href="binaries.html">binaries page</a>.
434
435<p>You cannot install GCC by itself on MSDOS; it will not compile under
436any MSDOS compiler except itself. You need to get the complete
437compilation package DJGPP, which includes binaries as well as sources,
438and includes all the necessary compilation tools and libraries.
439
440<hr />
441
442<h2><a name="TOC15"><a name="dsp16xx"></a>dsp16xx</h2>
443
444<p>A port to the AT&amp;T DSP1610 family of processors.
445
446<hr />
447
448<h2><a name="TOC16"><a name="*-*-freebsd*"></a>*-*-freebsd*</h2>
449
450<p>The version of binutils installed in <code>/usr/bin</code> is known to work unless
451otherwise specified in any per-architecture notes. However, binutils
4522.12.1 or greater is known to improve overall testsuite results.
453
454<p>For FreeBSD 1, FreeBSD 2 or any mutant a.out versions of FreeBSD 3: All
455configuration support and files as shipped with GCC 2.95 are still in
456place. FreeBSD 2.2.7 has been known to bootstrap completely; however,
457it is unknown which version of binutils was used (it is assumed that it
458was the system copy in <code>/usr/bin</code>) and C++ EH failures were noted.
459
460<p>Support for FreeBSD 1 is obsoleted in GCC 3.1.
461
462<p>For FreeBSD using the ELF file format: DWARF 2 debugging is now the
463default for all CPU architectures. It had been the default on
464FreeBSD/alpha since its inception. You may use <code>-gstabs</code> instead
465of <code>-g</code>, if you really want the old debugging format. There are
466no known issues with mixing object files and libraries with different
467debugging formats. Otherwise, this release of GCC should now match more
468of the configuration used in the stock FreeBSD configuration of GCC. In
469particular, <code>--enable-threads</code> is now configured by default.
470However, as a general user, do not attempt to replace the system
471compiler with this release. Known to bootstrap and check with good
472results on FreeBSD 3.0, 3.4, 4.0, 4.2, 4.3, 4.4, 4.5-STABLE and 5-CURRENT.
473
474<p>In principle, <code>--enable-threads</code> is now compatible with
475<code>--enable-libgcj</code> on FreeBSD. However, it has only been built
476and tested on <code>i386-*-freebsd4.5</code> and <code>alpha-*-freebsd5.0</code>.
477The static
478library may be incorrectly built (symbols are missing at link time).
479There is a rare timing-based startup hang (probably involves an
480assupmtion about the thread library). Multi-threaded boehm-gc (required for
481libjava) exposes severe threaded signal-handling bugs on FreeBSD before
4824.5-RELEASE. The alpha port may not fully bootstrap without some manual
483intervention: <code>gcjh</code> will crash with a floating-point exception while
484generating <code>java/lang/Double.h</code> (just copy the version built on
485<code>i386-*-freebsd*</code> and rerun the top-level <code>gmake</code> with no
486arguments and it
487should properly complete the bootstrap). Other CPU architectures
488supported by FreeBSD will require additional configuration tuning in, at
489the very least, both boehm-gc and libffi.
490
491<p>Shared <code>libgcc_s.so</code> is now built and installed by default.
492
493<hr />
494
495<h2><a name="TOC17"><a name="elxsi-elxsi-bsd"></a>elxsi-elxsi-bsd</h2>
496
497<p>The Elxsi's C compiler has known limitations that prevent it from
498compiling GCC. Please contact <a href="mailto:mrs@wrs.com">mrs@wrs.com</a> for more details.
499
500<p>Support for this processor is obsoleted in GCC 3.1.
501
502<hr />
503
504<h2><a name="TOC18"><a name="h8300-hms"></a>h8300-hms</h2>
505
506<p>Hitachi H8/300 series of processors.
507
508<p>Please have a look at our <a href="binaries.html">binaries page</a>.
509
510<p>The calling convention and structure layout has changed in release 2.6.
511All code must be recompiled. The calling convention now passes the
512first three arguments in function calls in registers. Structures are no
513longer a multiple of 2 bytes.
514
515<hr />
516
517<h2><a name="TOC19"><a name="hppa*-hp-hpux*"></a>hppa*-hp-hpux*</h2>
518
519<p>We <em>highly</em> recommend using gas/binutils 2.8 or newer on all hppa
520platforms; you may encounter a variety of problems when using the HP
521assembler. The HP assembler does not work with the <code>hppa64-hp-hpux11*</code>
522port.
523
524<p>Specifically, <code>-g</code> does not work on HP-UX (since that system
525uses a peculiar debugging format which GCC does not know about), unless you
526use GAS and GDB and configure GCC with the
527<a href="./configure.html#with-gnu-as"><code>--with-gnu-as</code></a> and
528<code>--with-as=<small>...</small></code> options.
529
530<p>If you wish to use the pa-risc 2.0 architecture support with a 32-bit
531runtime, you must use either the HP assembler, gas/binutils 2.11 or newer,
532or a recent
533<a href="ftp://sources.redhat.com/pub/binutils/snapshots">snapshot of gas</a>.
534
535<p>More specific information to <code>hppa*-hp-hpux*</code> targets follows.
536
537<hr />
538
539<h2><a name="TOC20"><a name="hppa*-hp-hpux9"></a>hppa*-hp-hpux9</h2>
540
541<p>The HP assembler has major problems on this platform. We've tried to work
542around the worst of the problems. However, those workarounds may be causing
543linker crashes in some circumstances; the workarounds also probably prevent
544shared libraries from working. Use the GNU assembler to avoid these problems.
545
546<p>The configuration scripts for GCC will also trigger a bug in the hpux9
547shell. To avoid this problem set <code>CONFIG_SHELL</code> to <code>/bin/ksh</code>
548and <code>SHELL</code> to <code>/bin/ksh</code> in your environment.
549
550<hr />
551
552<h2><a name="TOC21"><a name="hppa*-hp-hpux10"></a>hppa*-hp-hpux10</h2>
553
554<p>For hpux10.20, we <em>highly</em> recommend you pick up the latest sed patch
555<code>PHCO_19798</code> from HP. HP has two sites which provide patches free of
556charge:
557
558<ul>
559<li><a href="http://us-support.external.hp.com">US, Canada, Asia-Pacific, and
560Latin-America</a>
561<li><a href="http://europe-support.external.hp.com">Europe</a>
562</ul>
563
564<p>The HP assembler on these systems is much better than the hpux9 assembler,
565but still has some problems. Most notably the assembler inserts timestamps
566into each object file it creates, causing the 3-stage comparison test to fail
567during a <code>make bootstrap</code>. You should be able to continue by
568saying <code>make all</code> after getting the failure from <code>make
569bootstrap</code>.
570
571<hr />
572
573<h2><a name="TOC22"><a name="hppa*-hp-hpux11"></a>hppa*-hp-hpux11</h2>
574
575<p>GCC 3.0 and up support HP-UX 11. On 64-bit capable systems, there
576are two distinct ports. The <code>hppa2.0w-hp-hpux11*</code> port generates
577code for the 32-bit pa-risc runtime architecture. It uses the HP
578linker and is currently the default selected by config.guess. The
579optional <code>hppa64-hp-hpux11*</code> port generates 64-bit code for the
580pa-risc 2.0 architecture. It must be explicitly selected using the
581<code>--host=hppa64-hp-hpux11*</code> configure option. Different prefixes
582must be used if both ports are to be installed on the same system.
583
584<p>You must use GNU binutils 2.11 or above with the 32-bit port. Thread
585support is not currently implemented, so <code>--enable-threads</code> does
586not work. See:
587
588<ul>
589<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>
590<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>.
591</ul>
592
593<p>GCC 2.95.x is not supported under HP-UX 11 and cannot be used to
594compile GCC 3.0 and up. Refer to <a href="binaries.html">binaries</a> for
595information about obtaining precompiled GCC binaries for HP-UX.
596
597<p>GNU binutils 2.13 or later is recommended with the 64-bit port.
598The HP assembler is not supported. It is <em>highly</em> recommended
599that the GNU linker be used as well. Either binutils must be built
600prior to gcc, or a binary distribution of gcc or binutils must be
601obtained for the initial builds. When starting with a HP compiler,
602it is preferable to use the ANSI compiler as the bundled compiler
603only supports traditional C. Bootstrapping with the bundled compiler
604is tested infrequently and problems often arise because of the subtle
605differences in semantics between traditional and ISO C. There also
606have been problems reported with various binary distributions. This
607port still is undergoing significant development.
608
609<hr />
610
611<h2><a name="TOC23"><a name="i370-*-*"></a>i370-*-*</h2>
612
613<p>This port is very preliminary and has many known bugs. We hope to
614have a higher-quality port for this machine soon.
615
616<hr />
617
618<h2><a name="TOC24"><a name="*-*-linux-gnu"></a>*-*-linux-gnu</h2>
619
620<p>If you use glibc 2.2 (or 2.1.9x), GCC 2.95.2 won't install
621out-of-the-box. You'll get compile errors while building <code>libstdc++</code>.
622The patch <a href="glibc-2.2.patch">glibc-2.2.patch</a>, that is to be
623applied in the GCC source tree, fixes the compatibility problems.
624
625<p>
626
627<p>Currently Glibc 2.2.3 (and older releases) and GCC 3.0 are out of sync
628since the latest exception handling changes for GCC. Compiling glibc
629with GCC 3.0 will give a binary incompatible glibc and therefore cause
630lots of problems and might make your system completly unusable. This
631will definitly need fixes in glibc but might also need fixes in GCC. We
632strongly advise to wait for glibc 2.2.4 and to read the release notes of
633glibc 2.2.4 whether patches for GCC 3.0 are needed. You can use glibc
6342.2.3 with GCC 3.0, just do not try to recompile it.
635
636<hr />
637
638<h2><a name="TOC25"><a name="ix86-*-linux*oldld"></a>i?86-*-linux*oldld</h2>
639
640<p>Use this configuration to generate <code>a.out</code> binaries on Linux-based
641GNU systems if you do not have gas/binutils version 2.5.2 or later
642installed.
643
644<p>This configuration is obsoleted in GCC 3.1.
645
646<hr />
647
648<h2><a name="TOC26"><a name="ix86-*-linux*aout"></a>i?86-*-linux*aout</h2>
649
650<p>Use this configuration to generate <code>a.out</code> binaries on Linux-based
651GNU systems. This configuration is being superseded. You must use
652gas/binutils version 2.5.2 or later.
653
654<hr />
655
656<h2><a name="TOC27"><a name="ix86-*-linux*"></a>i?86-*-linux*</h2>
657
658<p>You will need binutils 2.9.1.0.15 or newer for exception handling to work.
659
660<p>If you receive Signal 11 errors when building on GNU/Linux, then it is
661possible you have a hardware problem. Further information on this can be
662found on <a href="http://www.bitwizard.nl/sig11/">www.bitwizard.nl</a>.
663
664<hr />
665
666<h2><a name="TOC28"><a name="ix86-*-sco"></a>i?86-*-sco</h2>
667
668<p>Compilation with RCC is recommended. Also, it may be a good idea to
669link with GNU malloc instead of the malloc that comes with the system.
670
671<hr />
672
673<h2><a name="TOC29"><a name="ix86-*-sco3.2v4"></a>i?86-*-sco3.2v4</h2>
674
675<p>Use this configuration for SCO release 3.2 version 4.
676
677<hr />
678
679<h2><a name="TOC30"><a name="ix86-*-sco3.2v5*"></a>i?86-*-sco3.2v5*</h2>
680
681<p>Use this for the SCO OpenServer Release 5 family of operating systems.
682
683<p>Unlike earlier versions of GCC, the ability to generate COFF with this
684target is no longer provided.
685
686<p>Earlier versions of GCC emitted DWARF 1 when generating ELF to allow
687the system debugger to be used. That support was too burdensome to
688maintain. GCC now emits only DWARF 2 for this target. This means you
689may use either the UDK debugger or GDB to debug programs built by this
690version of GCC.
691
692<p>Use of the <code>-march=pentiumpro</code> flag can result in
693unrecognized opcodes when using the native assembler on OS versions before
6945.0.6. (Support for P6 opcodes was added to the native ELF assembler in
695that version.) While it's rather rare to see these emitted by GCC yet,
696errors of the basic form:
697
698<pre> /usr/tmp/ccaNlqBc.s:22:unknown instruction: fcomip
699 /usr/tmp/ccaNlqBc.s:50:unknown instruction: fucomip
700</pre>
701
702<p>are symptoms of this problem. You may work around this by not
703building affected files with that flag, by using the GNU assembler, or
704by using the assembler provided with the current version of the OS.
705Users of GNU assembler should see the note below for hazards on doing
706so.
707
708<p>The native SCO assembler that is provided with the OS at no
709charge is normally required. If, however, you must be able to use
710the GNU assembler (perhaps you're compiling code with asms that
711require GAS syntax) you may configure this package using the flags
712<a href="./configure.html#with-gnu-as"><code>--with-gnu-as</code></a>. You must
713use a recent version of GNU binutils; versions past 2.9.1 seem to work
714well.
715
716<p>In general, the <code>--with-gnu-as</code> option isn't as well tested
717as the native assembler.
718
719<p>Look in <code>gcc/config/i386/sco5.h</code> (search for "messy") for
720additional OpenServer-specific flags.
721
722<p>Systems based on OpenServer before 5.0.4 (<code>uname -X</code>
723will tell you what you're running) require TLS597 from
724<a href="ftp://ftp.sco.com/TLS/">ftp://ftp.sco.com/TLS/</a>
725for C++ constructors and destructors to work right.
726
727<p>The system linker in (at least) 5.0.4 and 5.0.5 will sometimes
728do the wrong thing for a construct that GCC will emit for PIC
729code. This can be seen as execution testsuite failures when using
730<code>-fPIC</code> on <code>921215-1.c</code>, <code>931002-1.c</code>, <code>nestfunc-1.c</code>, and <code>gcov-1.c</code>.
731For 5.0.5, an updated linker that will cure this problem is
732available. You must install both
733<a href="ftp://ftp.sco.com/Supplements/rs505a/">ftp://ftp.sco.com/Supplements/rs505a/</a>
734and <a href="ftp://ftp.sco.com/SLS/">OSS499A</a>.
735
736<p>The dynamic linker in OpenServer 5.0.5 (earlier versions may show
737the same problem) aborts on certain G77-compiled programs. It's particularly
738likely to be triggered by building Fortran code with the <code>-fPIC</code> flag.
739Although it's conceivable that the error could be triggered by other
740code, only G77-compiled code has been observed to cause this abort.
741If you are getting core dumps immediately upon execution of your
742G77 program--and especially if it's compiled with <code>-fPIC</code>--try applying
743<a href="sco_osr5_g77.patch"><code>sco_osr5_g77.patch</code></a> to your <code>libf2c</code> and
744rebuilding GCC.
745Affected faults, when analyzed in a debugger, will show a stack
746backtrace with a fault occurring in <code>rtld()</code> and the program
747running as <code>/usr/lib/ld.so.1</code>. This problem has been reported to SCO
748engineering and will hopefully be addressed in later releases.
749
750<hr />
751
752<h2><a name="TOC31"><a name="ix86-*-udk"></a>i?86-*-udk</h2>
753
754<p>This target emulates the SCO Universal Development Kit and requires that
755package be installed. (If it is installed, you will have a
756<code>/udk/usr/ccs/bin/cc</code> file present.) It's very much like the
757<code>i?86-*-unixware7*</code> target
758but is meant to be used when hosting on a system where UDK isn't the
759default compiler such as OpenServer 5 or Unixware 2. This target will
760generate binaries that will run on OpenServer, Unixware 2, or Unixware 7,
761with the same warnings and caveats as the SCO UDK.
762
763<p>This target is a little tricky to build because we have to distinguish
764it from the native tools (so it gets headers, startups, and libraries
765from the right place) while making the tools not think we're actually
766building a cross compiler. The easiest way to do this is with a configure
767command like this:
768
769<pre> CC=/udk/usr/ccs/bin/cc <var>/your/path/to</var>/gcc/configure \
770 --host=i686-pc-udk --target=i686-pc-udk --program-prefix=udk-
771</pre>
772
773<p><em>You should substitute <code>i686</code> in the above command with the appropriate
774processor for your host.</em>
775
776<p>After the usual <code>make bootstrap</code> and
777<code>make install</code>, you can then access the UDK-targeted GCC
778tools by adding <code>udk-</code> before the commonly known name. For
779example, to invoke the C compiler, you would use <code>udk-gcc</code>.
780They will coexist peacefully with any native-target GCC tools you may
781have installed.
782
783<hr />
784
785<h2><a name="TOC32"><a name="ix86-*-isc"></a>i?86-*-isc</h2>
786
787<p>This configuration is obsoleted in GCC 3.1.
788
789<p>It may be a good idea to link with GNU malloc instead of the malloc that
790comes with the system.
791
792<p>In ISC version 4.1, <code>sed</code> core dumps when building
793<code>deduced.h</code>. Use the version of <code>sed</code> from version 4.0.
794
795<hr />
796
797<h2><a name="TOC33"><a name="ix86-ibm-aix"></a>i?86-ibm-aix</h2>
798
799<p>This configuration is obsoleted in GCC 3.1.
800
801<p>You need to use GAS version 2.1 or later, and LD from
802GNU binutils version 2.2 or later.
803
804<hr />
805
806<h2><a name="TOC34"><a name="ix86-sequent-bsd"></a>i?86-sequent-bsd</h2>
807
808<p>This configuration is obsoleted in GCC 3.1.
809
810<p>Go to the Berkeley universe before compiling.
811
812<hr />
813
814<h2><a name="TOC35"><a name="ix86-sequent-ptx1*"></a>i?86-sequent-ptx1*, i?86-sequent-ptx2*, i?86-sequent-sysv3*</h2>
815
816<p>This configuration is obsoleted in GCC 3.1.
817
818<p>You must install GNU <code>sed</code> before running <code>configure</code>.
819
820<p>The <code>fixproto</code> shell script may trigger a bug in the system shell.
821If you encounter this problem, upgrade your operating system or
822use <code>bash</code> (the GNU shell) to run <code>fixproto</code>.
823
824<hr />
825
826<h2><a name="TOC36"><a name="i860-intel-osf*"></a>i860-intel-osf*</h2>
827
828<p>All support for the i860 processor is obsoleted in GCC 3.1.
829
830<p>On the Intel Paragon (an i860 machine), if you are using operating
831system version 1.0, you will get warnings or errors about redefinition
832of <code>va_arg</code> when you build GCC.
833
834<p>If this happens, then you need to link most programs with the library
835<code>iclib.a</code>. You must also modify <code>stdio.h</code> as follows: before
836the lines
837
838<pre>#if defined(__i860__) &amp;&amp; !defined(_VA_LIST)
839#include &lt;va_list.h&gt;
840</pre>
841
842<p>insert the line
843
844<pre>#if __PGC__
845</pre>
846
847<p>and after the lines
848
849<pre>extern int vprintf(const char *, va_list );
850extern int vsprintf(char *, const char *, va_list );
851#endif
852</pre>
853
854<p>insert the line
855
856<pre>#endif /* __PGC__ */
857</pre>
858
859<p>These problems don't exist in operating system version 1.1.
860
861<hr />
862
863<h2><a name="TOC37"><a name="ia64-*-linux"></a>ia64-*-linux</h2>
864
865<p>IA-64 processor (also known as IPF, or Itanium Processor Family)
866running GNU/Linux.
867
868<p>The toolchain is not completely finished, so requirements will continue
869to change.
870GCC 3.0.1 and later require glibc 2.2.4.
871GCC 3.0.2 requires binutils from 2001-09-05 or later.
872GCC 3.0.1 requires binutils 2.11.1 or later.
873
874<p>None of the following versions of GCC has an ABI that is compatible
875with any of the other versions in this list, with the exception that
876Red Hat 2.96 and Trillian 000171 are compatible with each other:
8773.0.2, 3.0.1, 3.0, Red Hat 2.96, and Trillian 000717.
878This primarily affects C++ programs and programs that create shared libraries.
879Because of these ABI incompatibilities, GCC 3.0.2 is not recommended for
880user programs on GNU/Linux systems built using earlier compiler releases.
881GCC 3.0.2 is recommended for compiling linux, the kernel.
882GCC 3.0.2 is believed to be fully ABI compliant, and hence no more major
883ABI changes are expected.
884
885<hr />
886
887<h2><a name="TOC38"><a name="*-lynx-lynxos"></a>*-lynx-lynxos</h2>
888
889<p>LynxOS 2.2 and earlier comes with GCC 1.x already installed as
890<code>/bin/gcc</code>. You should compile with this instead of <code>/bin/cc</code>.
891You can tell GCC to use the GNU assembler and linker, by specifying
892<code>--with-gnu-as --with-gnu-ld</code> when configuring. These will produce
893COFF format object files and executables; otherwise GCC will use the
894installed tools, which produce <code>a.out</code> format executables.
895
896<hr />
897<!- rs6000-ibm-aix*, powerpc-ibm-aix* ->
898
899<h2><a name="TOC39"><a name="*-ibm-aix*"></a>*-ibm-aix*</h2>
900
901<p>AIX Make frequently has problems with GCC makefiles. GNU Make 3.76 or
902newer is recommended to build on this platform.
903
904<p>Errors involving <code>alloca</code> when building GCC generally are due
905to an incorrect definition of <code>CC</code> in the Makefile or mixing files
906compiled with the native C compiler and GCC. During the stage1 phase of
907the build, the native AIX compiler <strong>must</strong> be invoked as <code>cc</code>
908(not <code>xlc</code>). Once <code>configure</code> has been informed of
909<code>xlc</code>, one needs to use <code>make distclean</code> to remove the
910configure cache files and ensure that <code>CC</code> environment variable
911does not provide a definition that will confuse <code>configure</code>.
912If this error occurs during stage2 or later, then the problem most likely
913is the version of Make (see above).
914
915<p>The GNU Assembler incorrectly reports that it supports WEAK symbols on
916AIX which causes GCC to try to utilize weak symbol functionality which
917is not really supported on the platform. The native <code>as</code> and
918<code>ld</code> still are recommended. The native AIX tools do
919interoperate with GCC.
920
921<p>Building <code>libstdc++.a</code> requires a fix for a AIX Assembler bug
922APAR IY26685 (AIX 4.3) or APAR IY25528 (AIX 5.1).
923
924<p><code>libstdc++</code> in GCC 3.2 increments the major version number of the
925shared object and GCC installation places the <code>libstdc++.a</code>
926shared library in a common location which will overwrite the GCC 3.1
927version of the shared library. Applications either need to be
928re-linked against the new shared library or the GCC 3.1 version of the
929<code>libstdc++</code> shared object needs to be available to the AIX
930runtime loader. The GCC 3.1 <code>libstdc++.so.4</code> shared object can
931be installed for runtime dynamic loading using the following steps to
932set the <code>F_LOADONLY</code> flag in the shared object for <em>each</em>
933multilib <code>libstdc++.a</code> installed:
934
935<p>Extract the shared object from each the GCC 3.1 <code>libstdc++.a</code>
936archive:
937<pre> % ar -x libstdc++.a libstdc++.so.4
938</pre>
939
940<p>Enable the <code>F_LOADONLY</code> flag so that the shared object will be
941available for runtime dynamic loading, but not linking:
942<pre> % strip -e libstdc++.so.4
943</pre>
944
945<p>Archive the runtime-only shared object in the GCC 3.2
946<code>libstdc++.a</code> archive:
947<pre> % ar -q libstdc++.a libstdc++.so.4
948</pre>
949
950<p>Linking executables and shared libraries may produce warnings of
951duplicate symbols. The assembly files generated by GCC for AIX always
952have included multiple symbol definitions for certain global variable
953and function declarations in the original program. The warnings should
954not prevent the linker from producing a correct library or runnable
955executable.
956
957<p>AIX 4.3 utilizes a "large format" archive to support both 32-bit and
95864-bit object modules. The routines provided in AIX 4.3.0 and AIX 4.3.1
959to parse archive libraries did not handle the new format correctly.
960These routines are used by GCC and result in error messages during
961linking such as "not a COFF file". The version of the routines shipped
962with AIX 4.3.1 should work for a 32-bit environment. The <code>-g</code>
963option of the archive command may be used to create archives of 32-bit
964objects using the original "small format". A correct version of the
965routines is shipped with AIX 4.3.2 and above.
966
967<p>Some versions of the AIX binder (linker) can fail with a relocation
968overflow severe error when the <code>-bbigtoc</code> option is used to link
969GCC-produced object files into an executable that overflows the TOC. A fix
970for APAR IX75823 (OVERFLOW DURING LINK WHEN USING GCC AND -BBIGTOC) is
971available from IBM Customer Support and from its
972<a href="http://techsupport.services.ibm.com/">techsupport.services.ibm.com</a>
973website as PTF U455193.
974
975<p>The AIX 4.3.2.1 linker (bos.rte.bind_cmds Level 4.3.2.1) will dump core
976with a segmentation fault when invoked by any version of GCC. A fix for
977APAR IX87327 is available from IBM Customer Support and from its
978<a href="http://techsupport.services.ibm.com/">techsupport.services.ibm.com</a>
979website as PTF U461879. This fix is incorporated in AIX 4.3.3 and above.
980
981<p>The initial assembler shipped with AIX 4.3.0 generates incorrect object
982files. A fix for APAR IX74254 (64BIT DISASSEMBLED OUTPUT FROM COMPILER FAILS
983TO ASSEMBLE/BIND) is available from IBM Customer Support and from its
984<a href="http://techsupport.services.ibm.com/">techsupport.services.ibm.com</a>
985website as PTF U453956. This fix is incorporated in AIX 4.3.1 and above.
986
987<p>AIX provides National Language Support (NLS). Compilers and assemblers
988use NLS to support locale-specific representations of various data
989formats including floating-point numbers (e.g., <code>.</code> vs <code>,</code> for
990separating decimal fractions). There have been problems reported where
991GCC does not produce the same floating-point formats that the assembler
992expects. If one encounters this problem, set the <code>LANG</code>
993environment variable to <code>C</code> or <code>En_US</code>.
994
995<p>By default, GCC for AIX 4.1 and above produces code that can be used on
996both Power or PowerPC processors.
997
998<p>A default can be specified with the <code>-mcpu=<var>cpu_type</var></code>
999switch and using the configure option <code>--with-cpu-<var>cpu_type</var></code>.
1000
1001<hr />
1002
1003<h2><a name="TOC40"><a name="m32r-*-elf"></a>m32r-*-elf</h2>
1004
1005<p>Mitsubishi M32R processor.
1006This configuration is intended for embedded systems.
1007
1008<hr />
1009
1010<h2><a name="TOC41"><a name="m68000-hp-bsd"></a>m68000-hp-bsd</h2>
1011
1012<p>HP 9000 series 200 running BSD. Note that the C compiler that comes
1013with this system cannot compile GCC; contact <a href="mailto:law@cygnus.com">law@cygnus.com</a>
1014to get binaries of GCC for bootstrapping.
1015
1016<hr />
1017
1018<h2><a name="TOC42"><a name="m6811-elf"></a>m6811-elf</h2>
1019
1020<p>Motorola 68HC11 family micro controllers. These are used in embedded
1021applications. There are no standard Unix configurations.
1022
1023<hr />
1024
1025<h2><a name="TOC43"><a name="m6812-elf"></a>m6812-elf</h2>
1026
1027<p>Motorola 68HC12 family micro controllers. These are used in embedded
1028applications. There are no standard Unix configurations.
1029
1030<hr />
1031
1032<h2><a name="TOC44"><a name="m68k-altos"></a>m68k-altos</h2>
1033
1034<p>Altos 3068. This configuration is obsoleted in GCC 3.1.
1035
1036<p>You must use the GNU assembler, linker and debugger.
1037Also, you must fix a kernel bug.
1038
1039<hr />
1040
1041<h2><a name="TOC45"><a name="m68k-apple-aux"></a>m68k-apple-aux</h2>
1042
1043<p>Apple Macintosh running A/UX.
1044This configuration is obsoleted in GCC 3.1.
1045
1046<p>You may configure GCC to use either the system assembler and
1047linker or the GNU assembler and linker. You should use the GNU configuration
1048if you can, especially if you also want to use G++. You enable
1049that configuration with the <code>--with-gnu-as</code> and <code>--with-gnu-ld</code>
1050options to <code>configure</code>.
1051
1052<p>Note the C compiler that comes
1053with this system cannot compile GCC. You can find binaries of GCC
1054for bootstrapping on <code>jagubox.gsfc.nasa.gov</code>.
1055You will also a patched version of <code>/bin/ld</code> there that
1056raises some of the arbitrary limits found in the original.
1057
1058<hr />
1059
1060<h2><a name="TOC46"><a name="m68k-att-sysv"></a>m68k-att-sysv</h2>
1061
1062<p>AT&amp;T 3b1, a.k.a. 7300 PC. This version of GCC cannot
1063be compiled with the system C compiler, which is too buggy.
1064You will need to get a previous version of GCC and use it to
1065bootstrap. Binaries are available from the OSU-CIS archive, at
1066<a href="ftp://archive.cis.ohio-state.edu/pub/att7300/">ftp://archive.cis.ohio-state.edu/pub/att7300/</a>.
1067
1068<hr />
1069
1070<h2><a name="TOC47"><a name="m68k-bull-sysv"></a>m68k-bull-sysv</h2>
1071
1072<p>Bull DPX/2 series 200 and 300 with BOS-2.00.45 up to BOS-2.01.
1073This configuration is obsoleted in GCC 3.1.
1074
1075<p>GCC works
1076either with native assembler or GNU assembler. You can use
1077GNU assembler with native COFF generation by providing <code>--with-gnu-as</code> to
1078the configure script or use GNU assembler with stabs-in-COFF encapsulation
1079by providing <code>--with-gnu-as --stabs</code>. For any problem with the native
1080assembler or for availability of the DPX/2 port of GAS, contact
1081<a href="mailto:F.Pierresteguy@frcl.bull.fr">F.Pierresteguy@frcl.bull.fr</a>.
1082
1083<hr />
1084
1085<h2><a name="TOC48"><a name="m68k-crds-unos"></a>m68k-crds-unos</h2>
1086
1087<p>Use <code>configure unos</code> for building on Unos.
1088
1089<p>The Unos assembler is named <code>casm</code> instead of <code>as</code>. For some
1090strange reason linking <code>/bin/as</code> to <code>/bin/casm</code> changes the
1091behavior, and does not work. So, when installing GCC, you should
1092install the following script as <code>as</code> in the subdirectory where
1093the passes of GCC are installed:
1094
1095<pre>#!/bin/sh
1096casm $*
1097</pre>
1098
1099<p>The default Unos library is named <code>libunos.a</code> instead of
1100<code>libc.a</code>. To allow GCC to function, either change all
1101references to <code>-lc</code> in <code>gcc.c</code> to <code>-lunos</code> or link
1102<code>/lib/libc.a</code> to <code>/lib/libunos.a</code>.
1103
1104<p>When compiling GCC with the standard compiler, to overcome bugs in
1105the support of <code>alloca</code>, do not use <code>-O</code> when making stage 2.
1106Then use the stage 2 compiler with <code>-O</code> to make the stage 3
1107compiler. This compiler will have the same characteristics as the usual
1108stage 2 compiler on other systems. Use it to make a stage 4 compiler
1109and compare that with stage 3 to verify proper compilation.
1110
1111<p>(Perhaps simply defining <code>ALLOCA</code> in <code>x-crds</code> as described in
1112the comments there will make the above paragraph superfluous. Please
1113inform us of whether this works.)
1114
1115<p>Unos uses memory segmentation instead of demand paging, so you will need
1116a lot of memory. 5 Mb is barely enough if no other tasks are running.
1117If linking <code>cc1</code> fails, try putting the object files into a library
1118and linking from that library.
1119
1120<hr />
1121
1122<h2><a name="TOC49"><a name="m68k-hp-hpux"></a>m68k-hp-hpux</h2>
1123
1124<p>HP 9000 series 300 or 400 running HP-UX. HP-UX version 8.0 has a bug in
1125the assembler that prevents compilation of GCC. This
1126bug manifests itself during the first stage of compilation, while
1127building <code>libgcc2.a</code>:
1128
1129<pre>_floatdisf
1130cc1: warning: `-g' option not supported on this version of GCC
1131cc1: warning: `-g1' option not supported on this version of GCC
1132./xgcc: Internal compiler error: program as got fatal signal 11
1133</pre>
1134
1135<p>A patched version of the assembler is available as the file
1136<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
1137have HP software support, the patch can also be obtained directly from
1138HP, as described in the following note:
1139
1140<blockquote>
1141This is the patched assembler, to patch SR#1653-010439, where the
1142assembler aborts on floating point constants.
1143
1144<p>The bug is not really in the assembler, but in the shared library
1145version of the function "cvtnum(3c)". The bug on "cvtnum(3c)" is
1146SR#4701-078451. Anyway, the attached assembler uses the archive
1147library version of "cvtnum(3c)" and thus does not exhibit the bug.
1148</blockquote>
1149
1150<p>This patch is also known as PHCO_4484.
1151
1152<p>In addition, if you wish to use gas, you must use
1153gas version 2.1 or later, and you must use the GNU linker version 2.1 or
1154later. Earlier versions of gas relied upon a program which converted the
1155gas output into the native HP-UX format, but that program has not been
1156kept up to date. gdb does not understand that native HP-UX format, so
1157you must use gas if you wish to use gdb.
1158
1159<p>On HP-UX version 8.05, but not on 8.07 or more recent versions, the
1160<code>fixproto</code> shell script triggers a bug in the system shell. If you
1161encounter this problem, upgrade your operating system or use BASH (the
1162GNU shell) to run <code>fixproto</code>. This bug will cause the fixproto
1163program to report an error of the form:
1164
1165<pre>./fixproto: sh internal 1K buffer overflow
1166</pre>
1167
1168<p>To fix this, you can also change the first line of the fixproto script
1169to look like:
1170
1171<pre>#!/bin/ksh
1172</pre>
1173
1174<hr />
1175
1176<h2><a name="TOC50"><a name="m68k-*-nextstep*"></a>m68k-*-nextstep*</h2>
1177
1178<p>These configurations are obsoleted in GCC 3.1.
1179
1180<p>Current GCC versions probably do not work on version 2 of the NeXT
1181operating system.
1182
1183<p>On NeXTStep 3.0, the Objective-C compiler does not work, due,
1184apparently, to a kernel bug that it happens to trigger. This problem
1185does not happen on 3.1.
1186
1187<p>You absolutely <strong>must</strong> use GNU sed and GNU make on this platform.
1188
1189<p>On NeXTSTEP 3.x where x &lt; 3 the build of GCC will abort during
1190stage1 with an error message like this:
1191
1192<pre> _eh
1193 /usr/tmp/ccbbsZ0U.s:987:Unknown pseudo-op: .section
1194 /usr/tmp/ccbbsZ0U.s:987:Rest of line ignored. 1st junk character
1195 valued 95 (_).
1196</pre>
1197
1198<p>The reason for this is the fact that NeXT's assembler for these
1199versions of the operating system does not support the <code>.section</code>
1200pseudo op that's needed for full C++ exception functionality.
1201
1202<p>As NeXT's assembler is a derived work from GNU as, a free
1203replacement that does can be obtained at
1204<a href="ftp://ftp.next.peak.org:/next-ftp/next/apps/devtools/as.3.3.NIHS.s.tar.gz">ftp://ftp.next.peak.org:/next-ftp/next/apps/devtools/as.3.3.NIHS.s.tar.gz</a>.
1205
1206<p>If you try to build the integrated C++ &amp; C++ runtime libraries on this system
1207you will run into trouble with include files. The way to get around this is
1208to use the following sequence. Note you must have write permission to
1209the directory <var>prefix</var> you specified in the configuration process of GCC
1210for this sequence to work.
1211
1212<pre> cd bld-gcc
1213 make all-texinfo all-bison all-byacc all-binutils all-gas all-ld
1214 cd gcc
1215 make bootstrap
1216 make install-headers-tar
1217 cd ..
1218 make bootstrap3
1219</pre>
1220
1221<hr />
1222
1223<h2><a name="TOC51"><a name="m68k-ncr-*"></a>m68k-ncr-*</h2>
1224
1225<p>On the Tower models 4<var>n</var>0 and 6<var>n</var>0, by default a process is not
1226allowed to have more than one megabyte of memory. GCC cannot compile
1227itself (or many other programs) with <code>-O</code> in that much memory.
1228
1229<p>To solve this problem, reconfigure the kernel adding the following line
1230to the configuration file:
1231
1232<pre>MAXUMEM = 4096
1233</pre>
1234
1235<hr />
1236
1237<h2><a name="TOC52"><a name="m68k-sun"></a>m68k-sun</h2>
1238
1239<p>Sun 3. We do not provide a configuration file to use the Sun FPA by
1240default, because programs that establish signal handlers for floating
1241point traps inherently cannot work with the FPA.
1242
1243<hr />
1244
1245<h2><a name="TOC53"><a name="m68k-sun-sunos4.1.1"></a>m68k-sun-sunos4.1.1</h2>
1246
1247<p>It is reported that you may need the GNU assembler on this platform.
1248
1249<hr />
1250
1251<h2><a name="TOC54"><a name="m88k-*-svr3"></a>m88k-*-svr3</h2>
1252
1253<p>Motorola m88k running the AT&amp;T/Unisoft/Motorola V.3 reference port.
1254These configurations are obsoleted in GCC 3.1.
1255
1256<p>These systems tend to use the Green Hills C, revision 1.8.5, as the
1257standard C compiler. There are apparently bugs in this compiler that
1258result in object files differences between stage 2 and stage 3. If this
1259happens, make the stage 4 compiler and compare it to the stage 3
1260compiler. If the stage 3 and stage 4 object files are identical, this
1261suggests you encountered a problem with the standard C compiler; the
1262stage 3 and 4 compilers may be usable.
1263
1264<p>It is best, however, to use an older version of GCC for bootstrapping
1265if you have one.
1266
1267<hr />
1268
1269<h2><a name="TOC55"><a name="m88k-*-dgux"></a>m88k-*-dgux</h2>
1270
1271<p>Motorola m88k running DG/UX.
1272These configurations are obsoleted in GCC 3.1.
1273
1274<p>To build 88open BCS native or cross
1275compilers on DG/UX, specify the configuration name as
1276<code>m88k-*-dguxbcs</code> and build in the 88open BCS software development
1277environment. To build ELF native or cross compilers on DG/UX, specify
1278<code>m88k-*-dgux</code> and build in the DG/UX ELF development environment.
1279You set the software development environment by issuing
1280<code>sde-target</code> command and specifying either <code>m88kbcs</code> or
1281<code>m88kdguxelf</code> as the operand.
1282
1283<p>If you do not specify a configuration name, <code>configure</code> guesses the
1284configuration based on the current software development environment.
1285
1286<hr />
1287
1288<h2><a name="TOC56"><a name="m88k-tektronix-sysv3"></a>m88k-tektronix-sysv3</h2>
1289
1290<p>Tektronix XD88 running UTekV 3.2e.
1291These configurations are obsoleted in GCC 3.1.
1292
1293<p>Do not turn on
1294optimization while building stage1 if you bootstrap with
1295the buggy Green Hills compiler. Also, the bundled LAI
1296System V NFS is buggy so if you build in an NFS mounted
1297directory, start from a fresh reboot, or avoid NFS all together.
1298Otherwise you may have trouble getting clean comparisons
1299between stages.
1300
1301<hr />
1302
1303<h2><a name="TOC57"><a name="mips-*-*"></a>mips-*-*</h2>
1304
1305<p>If you use the 1.31 version of the MIPS assembler (such as was shipped
1306with Ultrix 3.1), you will need to use the <code>-fno-delayed-branch</code> switch
1307when optimizing floating point code. Otherwise, the assembler will
1308complain when the GCC compiler fills a branch delay slot with a
1309floating point instruction, such as <code>add.d</code>.
1310
1311<p>If on a MIPS system you get an error message saying "does not have gp
1312sections for all it's [sic] sectons [sic]", don't worry about it. This
1313happens whenever you use GAS with the MIPS linker, but there is not
1314really anything wrong, and it is okay to use the output file. You can
1315stop such warnings by installing the GNU linker.
1316
1317<p>It would be nice to extend GAS to produce the gp tables, but they are
1318optional, and there should not be a warning about their absence.
1319
1320<p>Users have reported some problems with version 2.0 of the MIPS
1321compiler tools that were shipped with Ultrix 4.1. Version 2.10
1322which came with Ultrix 4.2 seems to work fine.
1323
1324<p>Users have also reported some problems with version 2.20 of the
1325MIPS compiler tools that were shipped with RISC/os 4.x. The earlier
1326version 2.11 seems to work fine.
1327
1328<p>Some versions of the MIPS linker will issue an assertion failure
1329when linking code that uses <code>alloca</code> against shared
1330libraries on RISC-OS 5.0, and DEC's OSF/1 systems. This is a bug
1331in the linker, that is supposed to be fixed in future revisions.
1332To protect against this, GCC passes <code>-non_shared</code> to the
1333linker unless you pass an explicit <code>-shared</code> or
1334<code>-call_shared</code> switch.
1335
1336<h2><a name="TOC58"><a name="mips-mips-bsd"></a>mips-mips-bsd</h2>
1337
1338<p>MIPS machines running the MIPS operating system in BSD mode.
1339These configurations are obsoleted in GCC 3.1.
1340
1341<p>It's possible that some old versions of the system lack the functions
1342<code>memcpy</code>, <code>memmove</code>, <code>memcmp</code>, and <code>memset</code>. If your
1343system lacks these, you must remove or undo the definition of
1344<code>TARGET_MEM_FUNCTIONS</code> in <code>mips-bsd.h</code>.
1345
1346<p>If you use the MIPS C compiler to bootstrap, it may be necessary
1347to increase its table size for switch statements with the
1348<code>-Wf,-XNg1500</code> option. If you use the <code>-O2</code>
1349optimization option, you also need to use <code>-Olimit 3000</code>.
1350Both of these options are automatically generated in the
1351<code>Makefile</code> that the shell script <code>configure</code> builds.
1352If you override the <code>CC</code> make variable and use the MIPS
1353compilers, you may need to add <code>-Wf,-XNg1500 -Olimit 3000</code>.
1354
1355<hr />
1356
1357<h2><a name="TOC59"><a name="mips-dec-*"></a>mips-dec-*</h2>
1358
1359<p>These configurations are obsoleted in GCC 3.1.
1360
1361<p>MIPS-based DECstations can support three different personalities:
1362Ultrix, DEC OSF/1, and OSF/rose. (Alpha-based DECstation products have
1363a configuration name beginning with <code>alpha*-dec</code>.) To configure GCC
1364for these platforms use the following configurations:
1365
1366<dl>
1367<dt><code>mips-dec-ultrix</code>
1368<dd>Ultrix configuration.
1369
1370<br><dt><code>mips-dec-osf1</code>
1371<dd>DEC's version of OSF/1.
1372
1373<br><dt><code>mips-dec-osfrose</code>
1374<dd>Open Software Foundation reference port of OSF/1 which uses the
1375OSF/rose object file format instead of ECOFF. Normally, you
1376would not select this configuration.
1377</dl>
1378
1379<p>If you use the MIPS C compiler to bootstrap, it may be necessary
1380to increase its table size for switch statements with the
1381<code>-Wf,-XNg1500</code> option. If you use the <code>-O2</code>
1382optimization option, you also need to use <code>-Olimit 3000</code>.
1383Both of these options are automatically generated in the
1384<code>Makefile</code> that the shell script <code>configure</code> builds.
1385If you override the <code>CC</code> make variable and use the MIPS
1386compilers, you may need to add <code>-Wf,-XNg1500 -Olimit 3000</code>.
1387
1388<hr />
1389
1390<h2><a name="TOC60"><a name="mips-mips-riscos*"></a>mips-mips-riscos*</h2>
1391
1392<p>These configurations are obsoleted in GCC 3.1.
1393
1394<p>If you use the MIPS C compiler to bootstrap, it may be necessary
1395to increase its table size for switch statements with the
1396<code>-Wf,-XNg1500</code> option. If you use the <code>-O2</code>
1397optimization option, you also need to use <code>-Olimit 3000</code>.
1398Both of these options are automatically generated in the
1399<code>Makefile</code> that the shell script <code>configure</code> builds.
1400If you override the <code>CC</code> make variable and use the MIPS
1401compilers, you may need to add <code>-Wf,-XNg1500 -Olimit 3000</code>.
1402
1403<p>MIPS computers running RISC-OS can support four different
1404personalities: default, BSD 4.3, System V.3, and System V.4
1405(older versions of RISC-OS don't support V.4). To configure GCC
1406for these platforms use the following configurations:
1407
1408<dl>
1409<dt><code>mips-mips-riscos<var>rev</var></code>
1410<dd>Default configuration for RISC-OS, revision <var>rev</var>.
1411
1412<br><dt><code>mips-mips-riscos<var>rev</var>bsd</code>
1413<dd>BSD 4.3 configuration for RISC-OS, revision <var>rev</var>.
1414
1415<br><dt><code>mips-mips-riscos<var>rev</var>sysv4</code>
1416<dd>System V.4 configuration for RISC-OS, revision <var>rev</var>.
1417
1418<hr />
1419<br><dt><code>mips-mips-riscos<var>rev</var>sysv</code>
1420<dd>System V.3 configuration for RISC-OS, revision <var>rev</var>.
1421</dl>
1422
1423<p>The revision <code>rev</code> mentioned above is the revision of
1424RISC-OS to use. You must reconfigure GCC when going from a
1425RISC-OS revision 4 to RISC-OS revision 5. This has the effect of
1426avoiding a linker bug.
1427
1428<hr />
1429
1430<h2><a name="TOC61"><a name="mips-sgi-irix4"></a>mips-sgi-irix4</h2>
1431
1432<p>This configuration is obsoleted in GCC 3.1.
1433
1434<p>In order to compile GCC on an SGI running IRIX 4, the "c.hdr.lib"
1435option must be installed from the CD-ROM supplied from Silicon Graphics.
1436This is found on the 2nd CD in release 4.0.1.
1437
1438<p>On IRIX version 4.0.5F, and perhaps on some other versions as well,
1439there is an assembler bug that reorders instructions incorrectly. To
1440work around it, specify the target configuration
1441<code>mips-sgi-irix4loser</code>. This configuration inhibits assembler
1442optimization.
1443
1444<p>In a compiler configured with target <code>mips-sgi-irix4</code>, you can turn
1445off assembler optimization by using the <code>-noasmopt</code> option. This
1446compiler option passes the option <code>-O0</code> to the assembler, to
1447inhibit reordering.
1448
1449<p>The <code>-noasmopt</code> option can be useful for testing whether a problem
1450is due to erroneous assembler reordering. Even if a problem does not go
1451away with <code>-noasmopt</code>, it may still be due to assembler
1452reordering--perhaps GCC itself was miscompiled as a result.
1453
1454<p>You may get the following warning on IRIX 4 platforms, it can be safely
1455ignored.
1456<pre> warning: foo.o does not have gp tables for all its sections.
1457</pre>
1458
1459<hr />
1460
1461<h2><a name="TOC62"><a name="mips-sgi-irix5"></a>mips-sgi-irix5</h2>
1462
1463<p>This configuration has considerable problems, which will be fixed in a
1464future release.
1465
1466<p>In order to compile GCC on an SGI running IRIX 5, the "compiler_dev.hdr"
1467subsystem must be installed from the IDO CD-ROM supplied by Silicon
1468Graphics. It is also available for download from
1469<a href="http://www.sgi.com/developers/devtools/apis/ido.html">http://www.sgi.com/developers/devtools/apis/ido.html</a>.
1470
1471<p><code>make compare</code> may fail on version 5 of IRIX unless you add
1472<code>-save-temps</code> to <code>CFLAGS</code>. On these systems, the name of the
1473assembler input file is stored in the object file, and that makes
1474comparison fail if it differs between the <code>stage1</code> and
1475<code>stage2</code> compilations. The option <code>-save-temps</code> forces a
1476fixed name to be used for the assembler input file, instead of a
1477randomly chosen name in <code>/tmp</code>. Do not add <code>-save-temps</code>
1478unless the comparisons fail without that option. If you do you
1479<code>-save-temps</code>, you will have to manually delete the <code>.i</code> and
1480<code>.s</code> files after each series of compilations.
1481
1482<p>If you use the MIPS C compiler to bootstrap, it may be necessary
1483to increase its table size for switch statements with the
1484<code>-Wf,-XNg1500</code> option. If you use the <code>-O2</code>
1485optimization option, you also need to use <code>-Olimit 3000</code>.
1486
1487<p>To enable debugging under IRIX 5, you must use GNU <code>as</code> 2.11.2
1488or later,
1489and use the <code>--with-gnu-as</code> configure option when configuring GCC.
1490GNU <code>as</code> is distributed as part of the binutils package.
1491When using release 2.11.2, you need to apply a patch
1492<a href="http://sources.redhat.com/ml/binutils/2001-07/msg00352.html">http://sources.redhat.com/ml/binutils/2001-07/msg00352.html</a>
1493which will be included in the next release of binutils.
1494
1495<p>When building GCC, the build process loops rebuilding <code>cc1</code> over
1496and over again. This happens on <code>mips-sgi-irix5.2</code>, and possibly
1497other platforms. It has been reported that this is a known bug in the
1498<code>make</code> shipped with IRIX 5.2. We recommend you use GNU
1499<code>make</code> instead of the vendor supplied <code>make</code> program;
1500however, you may have success with <code>smake</code> on IRIX 5.2 if you do
1501not have GNU <code>make</code> available.
1502
1503<hr />
1504
1505<h2><a name="TOC63"><a name="mips-sgi-irix6"></a>mips-sgi-irix6</h2>
1506
1507<p>If you are using IRIX <code>cc</code> as your bootstrap compiler, you must
1508ensure that the N32 ABI is in use. To test this, compile a simple C
1509file with <code>cc</code> and then run <code>file</code> on the
1510resulting object file. The output should look like:
1511
1512<pre>test.o: ELF N32 MSB <small>...</small>
1513</pre>
1514
1515<p>If you see:
1516
1517<pre>test.o: ELF 32-bit MSB <small>...</small>
1518</pre>
1519
1520<p>or
1521
1522<pre>test.o: ELF 64-bit MSB <small>...</small>
1523</pre>
1524
1525<p>then your version of <code>cc</code> uses the O32 or N64 ABI by default. You
1526should set the environment variable <code>CC</code> to <code>cc -n32</code>
1527before configuring GCC.
1528
1529<p>If you want the resulting <code>gcc</code> to run on old 32-bit systems
1530with the MIPS R4400 CPU, you need to ensure that only code for the mips3
1531instruction set architecture (ISA) is generated. While GCC 3.x does
1532this correctly, both GCC 2.95 and SGI's MIPSpro <code>cc</code> may change
1533the ISA depending on the machine where GCC is built. Using one of them
1534as the bootstrap compiler may result in mips4 code, which won't run at
1535all on mips3-only systems. For the test program above, you should see:
1536
1537<pre>test.o: ELF N32 MSB mips-3 <small>...</small>
1538</pre>
1539
1540<p>If you get:
1541
1542<pre>test.o: ELF N32 MSB mips-4 <small>...</small>
1543</pre>
1544
1545<p>instead, you should set the environment variable <code>CC</code> to <code>cc
1546-n32 -mips3</code> or <code>gcc -mips3</code> respectively before configuring GCC.
1547
1548<p>GCC on IRIX 6 is usually built to support both the N32 and N64 ABIs. If
1549you build GCC on a system that doesn't have the N64 libraries installed,
1550you need to configure with <code>--disable-multilib</code> so GCC doesn't
1551try to use them. Look for <code>/usr/lib64/libc.so.1</code> to see if you
1552have the 64-bit libraries installed.
1553
1554<p>You must <em>not</em> use GNU <code>as</code> (which isn't built anyway as of
1555binutils 2.11.2) on IRIX 6 platforms; doing so will only cause problems.
1556
1557<p>GCC does not currently support generating O32 ABI binaries in the
1558<code>mips-sgi-irix6</code> configurations. It is possible to create a GCC
1559with O32 ABI only support by configuring it for the <code>mips-sgi-irix5</code>
1560target and using a patched GNU <code>as</code> 2.11.2 as documented in the
1561<a href="#mips-sgi-irix5"><code>mips-sgi-irix5</code></a> section above. Using the
1562native assembler requires patches to GCC which will be included in a
1563future release. It is
1564expected that O32 ABI support will be available again in a future release.
1565
1566<p>The <code>--enable-threads</code> option doesn't currently work, a patch is
1567in preparation for a future release. The <code>--enable-libgcj</code>
1568option is disabled by default: IRIX 6 uses a very low default limit
1569(20480) for the command line length. Although libtool contains a
1570workaround for this problem, at least the N64 <code>libgcj</code> is known not
1571to build despite this, running into an internal error of the native
1572<code>ld</code>. A sure fix is to increase this limit (<code>ncargs</code>) to
1573its maximum of 262144 bytes. If you have root access, you can use the
1574<code>systune</code> command to do this.
1575
1576<p>GCC does not correctly pass/return structures which are
1577smaller than 16 bytes and which are not 8 bytes. The problem is very
1578involved and difficult to fix. It affects a number of other targets also,
1579but IRIX 6 is affected the most, because it is a 64-bit target, and 4 byte
1580structures are common. The exact problem is that structures are being padded
1581at the wrong end, e.g. a 4 byte structure is loaded into the lower 4 bytes
1582of the register when it should be loaded into the upper 4 bytes of the
1583register.
1584
1585<p>GCC is consistent with itself, but not consistent with the SGI C compiler
1586(and the SGI supplied runtime libraries), so the only failures that can
1587happen are when there are library functions that take/return such
1588structures. There are very few such library functions. Currently this
1589is known to affect <code>inet_ntoa</code>, <code>inet_lnaof</code>,
1590<code>inet_netof</code>, <code>inet_makeaddr</code>, and <code>semctl</code>. Until the
1591bug is fixed, GCC contains workarounds for the known affected functions.
1592
1593<p>See <a href="http://freeware.sgi.com/">http://freeware.sgi.com/</a> for more
1594information about using GCC on IRIX platforms.
1595
1596<hr />
1597
1598<h2><a name="TOC64"><a name="mips-sony-sysv"></a>mips-sony-sysv</h2>
1599
1600<p>Sony MIPS NEWS. This configuration is obsoleted in GCC 3.1.
1601
1602<p>This works in NEWSOS 5.0.1, but not in 5.0.2 (which uses ELF instead of
1603COFF). In particular, the linker does not like the code generated by
1604GCC when shared libraries are linked in.
1605
1606<hr />
1607
1608<h2><a name="TOC65"><a name="ns32k-encore"></a>ns32k-encore</h2>
1609
1610<p>This configuration is obsoleted in GCC 3.1.
1611
1612<p>Encore ns32000 system. Encore systems are supported only under BSD.
1613
1614<hr />
1615
1616<h2><a name="TOC66"><a name="ns32k-*-genix"></a>ns32k-*-genix</h2>
1617
1618<p>National Semiconductor ns32000 system. This configuration is obsoleted
1619in GCC 3.1.
1620
1621<p>Genix has bugs in <code>alloca</code> and <code>malloc</code>; you must get the
1622compiled versions of these from GNU Emacs.
1623
1624<hr />
1625
1626<h2><a name="TOC67"><a name="ns32k-sequent"></a>ns32k-sequent</h2>
1627
1628<p>This configuration is obsoleted in GCC 3.1.
1629
1630<p>Go to the Berkeley universe before compiling.
1631
1632<hr />
1633
1634<h2><a name="TOC68"><a name="ns32k-utek"></a>ns32k-utek</h2>
1635
1636<p>UTEK ns32000 system ("merlin"). This configuration is obsoleted in
1637GCC 3.1.
1638
1639<p>The C compiler that comes with this system cannot compile GCC; contact
1640<code>tektronix!reed!mason</code> to get binaries of GCC for bootstrapping.
1641
1642<hr />
1643
1644<h2><a name="TOC69"><a name="powerpc*-*-*"></a>powerpc-*-*</h2>
1645
1646<p>You can specify a default version for the <code>-mcpu=<var>cpu_type</var></code>
1647switch by using the configure option <code>--with-cpu-<var>cpu_type</var></code>.
1648
1649<hr />
1650
1651<h2><a name="TOC70"><a name="powerpc-*-darwin*"></a>powerpc-*-darwin*</h2>
1652
1653<p>PowerPC running Darwin (Mac OS X kernel).
1654
1655<p>GCC 3.0 does not support Darwin, but 3.1 and later releases will work.
1656
1657<p>Pre-installed versions of Mac OS X may not include any developer tools,
1658meaning that you will not be able to build GCC from source. Tool
1659binaries are available at
1660<a href="http://www.opensource.apple.com/projects/darwin">http://www.opensource.apple.com/projects/darwin</a> (free
1661registration required).
1662
1663<p>Versions of the assembler prior to "cctools-364" cannot handle the
16644-argument form of <code>rlwinm</code> and related mask-using instructions. Darwin
16651.3 (Mac OS X 10.0) uses cctools-353 for instance. To get cctools-364,
1666check out <code>cctools</code> with tag <code>Apple-364</code>, build it, and
1667install the assembler as <code>usr/bin/as</code>. See
1668<a href="http://www.opensource.apple.com/tools/cvs/docs.html">http://www.opensource.apple.com/tools/cvs/docs.html</a> for details.
1669
1670<p>Also, the default stack limit of 512K is too small, and a bootstrap will
1671typically fail when self-compiling <code>expr.c</code>. Set the stack to 800K
1672or more, for instance by doing <code>limit stack 800</code>. It's also
1673convenient to use the GNU preprocessor instead of Apple's during the
1674first stage of bootstrapping; this is automatic when doing <code>make
1675bootstrap</code>, but to do it from the toplevel objdir you will need to say
1676<code>make CC='cc -no-cpp-precomp' bootstrap</code>.
1677
1678<p>Note that the version of GCC shipped by Apple typically includes a
1679number of extensions not available in a standard GCC release. These
1680extensions are generally specific to Mac programming.
1681
1682<hr />
1683
1684<h2><a name="TOC71"><a name="powerpc-*-elf"></a>powerpc-*-elf, powerpc-*-sysv4</h2>
1685
1686<p>PowerPC system in big endian mode, running System V.4.
1687
1688<hr />
1689
1690<h2><a name="TOC72"><a name="powerpc-*-linux-gnu*"></a>powerpc-*-linux-gnu*</h2>
1691
1692<p>You will need
1693<a href="ftp://ftp.kernel.org/pub/linux/devel/binutils">binutils 2.13.90.0.10</a>
1694or newer for a working GCC.
1695
1696<hr />
1697
1698<h2><a name="TOC73"><a name="powerpc-*-netbsd*"></a>powerpc-*-netbsd*</h2>
1699
1700<p>PowerPC system in big endian mode running NetBSD. To build the
1701documentation you will need Texinfo version 4.1 (NetBSD 1.5.1 included
1702Texinfo version 3.12).
1703
1704<hr />
1705
1706<h2><a name="TOC74"><a name="powerpc-*-eabiaix"></a>powerpc-*-eabiaix</h2>
1707
1708<p>Embedded PowerPC system in big endian mode with <code>-mcall-aix</code> selected as
1709the default.
1710
1711<hr />
1712
1713<h2><a name="TOC75"><a name="powerpc-*-eabisim"></a>powerpc-*-eabisim</h2>
1714
1715<p>Embedded PowerPC system in big endian mode for use in running under the
1716PSIM simulator.
1717
1718<hr />
1719
1720<h2><a name="TOC76"><a name="powerpc-*-eabi"></a>powerpc-*-eabi</h2>
1721
1722<p>Embedded PowerPC system in big endian mode.
1723
1724<hr />
1725
1726<h2><a name="TOC77"><a name="powerpcle-*-elf"></a>powerpcle-*-elf, powerpcle-*-sysv4</h2>
1727
1728<p>PowerPC system in little endian mode, running System V.4.
1729
1730<hr />
1731
1732<h2><a name="TOC78"><a name="powerpcle-*-eabisim"></a>powerpcle-*-eabisim</h2>
1733
1734<p>Embedded PowerPC system in little endian mode for use in running under
1735the PSIM simulator.
1736
1737<hr />
1738
1739<h2><a name="TOC79"><a name="powerpcle-*-eabi"></a>powerpcle-*-eabi</h2>
1740
1741<p>Embedded PowerPC system in little endian mode.
1742
1743<hr />
1744
1745<h2><a name="TOC80"><a name="powerpcle-*-winnt"></a>powerpcle-*-winnt, powerpcle-*-pe</h2>
1746
1747<p>PowerPC system in little endian mode running Windows NT.
1748
1749<hr />
1750
1751<h2><a name="TOC81"><a name="romp-*-aos"></a>romp-*-aos, romp-*-mach</h2>
1752
1753<p>These configurations are obsoleted in GCC 3.1.
1754
1755<p>We recommend you compile GCC with an earlier version of itself; if you
1756compile GCC with <code>hc</code>, the Metaware compiler, it will work, but
1757you will get mismatches between the stage 2 and stage 3 compilers in
1758various files. These errors are minor differences in some
1759floating-point constants and can be safely ignored; the stage 3 compiler
1760is correct.
1761
1762<hr />
1763
1764<h2><a name="TOC82"><a name="s390-*-linux*"></a>s390-*-linux*</h2>
1765
1766<p>S/390 system running Linux for S/390.
1767
1768<hr />
1769
1770<h2><a name="TOC83"><a name="s390x-*-linux*"></a>s390x-*-linux*</h2>
1771
1772<p>zSeries system (64-bit) running Linux for zSeries.
1773
1774<hr />
1775
1776<h2><a name="TOC84"><a name="*-*-solaris2*"></a>*-*-solaris2*</h2>
1777
1778<p>Sun does not ship a C compiler with Solaris 2. To bootstrap and install
1779GCC you first have to install a pre-built compiler, see our
1780<a href="binaries.html">binaries page</a> for details.
1781
1782<p>The Solaris 2 <code>/bin/sh</code> will often fail to configure
1783<code>libstdc++-v3</code>, <code>boehm-gc</code> or
1784<code>libjava</code>. If you encounter this problem, set <code>CONFIG_SHELL</code> to
1785<code>/bin/ksh</code> in your environment before running <code>configure</code>.
1786
1787<p>Solaris 2 comes with a number of optional OS packages. Some of these
1788packages are needed to use GCC fully, namely <code>SUNWarc</code>,
1789<code>SUNWbtool</code>, <code>SUNWesu</code>, <code>SUNWhea</code>, <code>SUNWlibm</code>,
1790<code>SUNWsprot</code>, and <code>SUNWtoo</code>. If you did not install all
1791optional packages when installing Solaris 2, you will need to verify that
1792the packages that GCC needs are installed.
1793
1794<p>To check whether an optional package is installed, use
1795the <code>pkginfo</code> command. To add an optional package, use the
1796<code>pkgadd</code> command. For further details, see the Solaris 2
1797documentation.
1798
1799<p>Trying to use the linker and other tools in
1800<code>/usr/ucb</code> to install GCC has been observed to cause trouble.
1801For example, the linker may hang indefinitely. The fix is to remove
1802<code>/usr/ucb</code> from your <code>PATH</code>.
1803
1804<p>All releases of GNU binutils prior to 2.11.2 have known bugs on this
1805platform. We recommend the use of GNU binutils 2.11.2 or the vendor
1806tools (Sun <code>as</code>, Sun <code>ld</code>).
1807
1808<p>Sun bug 4296832 turns up when compiling X11 headers with GCC 2.95 or
1809newer: <code>g++</code> will complain that types are missing. These headers assume
1810that omitting the type means <code>int</code>; this assumption worked for C89 but
1811is wrong for C++, and is now wrong for C99 also.
1812
1813<p><code>g++</code> accepts such (invalid) constructs with the option
1814<code>-fpermissive</code>; it
1815will assume that any missing type is <code>int</code> (as defined by C89).
1816
1817<p>There are patches for Solaris 2.6 (105633-56 or newer for SPARC,
1818106248-42 or newer for Intel), Solaris 7 (108376-21 or newer for SPARC,
1819108377-20 for Intel), and Solaris 8 (108652-24 or newer for SPARC,
1820108653-22 for Intel) that fix this bug.
1821
1822<hr />
1823
1824<h2><a name="TOC85"><a name="sparc-sun-solaris2*"></a>sparc-sun-solaris2*</h2>
1825
1826<p>When GCC is configured to use binutils 2.11.2 or later the binaries
1827produced are smaller than the ones produced using Sun's native tools;
1828this difference is quite significant for binaries containing debugging
1829information.
1830
1831<p>Sun <code>as</code> 4.x is broken in that it cannot cope with long symbol names.
1832A typical error message might look similar to the following:
1833
1834<pre>/usr/ccs/bin/as: "/var/tmp/ccMsw135.s", line 11041: error:
1835 can't compute value of an expression involving an external symbol.
1836</pre>
1837
1838<p>This is Sun bug 4237974. This is fixed with patch 108908-02 for Solaris
18392.6 and has been fixed in later (5.x) versions of the assembler,
1840starting with Solaris 7.
1841
1842<p>Starting with Solaris 7, the operating system is capable of executing
184364-bit SPARC V9 binaries. GCC 3.1 and later properly supports
1844this; the <code>-m64</code> option enables 64-bit code generation.
1845However, if all you want is code tuned for the UltraSPARC CPU, you
1846should try the <code>-mtune=ultrasparc</code> option instead, which produces
1847code that, unlike full 64-bit code, can still run on non-UltraSPARC
1848machines.
1849
1850<p>When configuring on a Solaris 7 or later system that is running a kernel
1851that supports only 32-bit binaries, one must configure with
1852<code>--disable-multilib</code>, since we will not be able to build the
185364-bit target libraries.
1854
1855<hr />
1856
1857<h2><a name="TOC86"><a name="sparc-sun-solaris2.7"></a>sparc-sun-solaris2.7</h2>
1858
1859<p>Sun patch 107058-01 (1999-01-13) for Solaris 7/SPARC triggers a bug in
1860the dynamic linker. This problem (Sun bug 4210064) affects GCC 2.8
1861and later, including all EGCS releases. Sun formerly recommended
1862107058-01 for all Solaris 7 users, but around 1999-09-01 it started to
1863recommend it only for people who use Sun's compilers.
1864
1865<p>Here are some workarounds to this problem:
1866<ul>
1867<li>Do not install Sun patch 107058-01 until after Sun releases a
1868complete patch for bug 4210064. This is the simplest course to take,
1869unless you must also use Sun's C compiler. Unfortunately 107058-01
1870is preinstalled on some new Solaris 7-based hosts, so you may have to
1871back it out.
1872
1873<li>Copy the original, unpatched Solaris 7
1874<code>/usr/ccs/bin/as</code> into
1875<code>/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/3.1/as</code>,
1876adjusting the latter name to fit your local conventions and software
1877version numbers.
1878
1879<li>Install Sun patch 106950-03 (1999-05-25) or later. Nobody with
1880both 107058-01 and 106950-03 installed has reported the bug with GCC
1881and Sun's dynamic linker. This last course of action is riskiest,
1882for two reasons. First, you must install 106950 on all hosts that
1883run code generated by GCC; it doesn't suffice to install it only on
1884the hosts that run GCC itself. Second, Sun says that 106950-03 is
1885only a partial fix for bug 4210064, but Sun doesn't know whether the
1886partial fix is adequate for GCC. Revision -08 or later should fix
1887the bug. The current (as of 2001-09-24) revision is -14, and is included in
1888the Solaris 7 Recommended Patch Cluster.
1889</ul>
1890
1891<p>
1892<hr />
1893
1894<h2><a name="TOC87"><a name="sparc-sun-sunos4*"></a>sparc-sun-sunos4*</h2>
1895
1896<p>A bug in the SunOS 4 linker will cause it to crash when linking
1897<code>-fPIC</code> compiled objects (and will therefore not allow you to build
1898shared libraries).
1899
1900<p>To fix this problem you can either use the most recent version of
1901binutils or get the latest SunOS 4 linker patch (patch ID 100170-10)
1902from Sun's patch site.
1903
1904<p>Sometimes on a Sun 4 you may observe a crash in the program
1905<code>genflags</code> or <code>genoutput</code> while building GCC. This is said to
1906be due to a bug in <code>sh</code>. You can probably get around it by running
1907<code>genflags</code> or <code>genoutput</code> manually and then retrying the
1908<code>make</code>.
1909
1910<hr />
1911
1912<h2><a name="TOC88"><a name="sparc-unknown-linux-gnulibc1"></a>sparc-unknown-linux-gnulibc1</h2>
1913
1914<p>It has been reported that you might need
1915<a href="ftp://ftp.yggdrasil.com/private/hjl">binutils 2.8.1.0.23</a>
1916for this platform, too.
1917
1918<hr />
1919
1920<h2><a name="TOC89"><a name="sparc-*-linux*"></a>sparc-*-linux*</h2>
1921
1922<p>GCC versions 3.0 and higher require binutils 2.11.2 and glibc 2.2.4
1923or newer on this platform. All earlier binutils and glibc
1924releases mishandled unaligned relocations on <code>sparc-*-*</code> targets.
1925
1926<hr />
1927
1928<h2><a name="TOC90"><a name="sparc64-*-*"></a>sparc64-*-*</h2>
1929
1930<p>GCC version 2.95 is not able to compile code correctly for
1931<code>sparc64</code> targets. Users of the Linux kernel, at least,
1932can use the <code>sparc32</code> program to start up a new shell
1933invocation with an environment that causes <code>configure</code> to
1934recognize (via <code>uname -a</code>) the system as <code>sparc-*-*</code> instead.
1935
1936<hr />
1937
1938<h2><a name="TOC91"><a name="sparcv9-*-solaris2*"></a>sparcv9-*-solaris2*</h2>
1939
1940<p>The following compiler flags must be specified in the configure
1941step in order to bootstrap this target with the Sun compiler:
1942
1943<pre> % CC="cc -xildoff -xarch=v9" <var>srcdir</var>/configure [<var>options</var>] [<var>target</var>]
1944</pre>
1945
1946<p><code>-xildoff</code> turns off the incremental linker, and <code>-xarch=v9</code>
1947specifies the v9 architecture to the Sun linker and assembler.
1948
1949<hr />
1950
1951<h2><a name="TOC92"><a name="%23*-*-sysv*"></a>*-*-sysv*</h2>
1952
1953<p>On System V release 3, you may get this error message
1954while linking:
1955
1956<pre>ld fatal: failed to write symbol name <var>something</var>
1957 in strings table for file <var>whatever</var>
1958</pre>
1959
1960<p>This probably indicates that the disk is full or your ulimit won't allow
1961the file to be as large as it needs to be.
1962
1963<p>This problem can also result because the kernel parameter <code>MAXUMEM</code>
1964is too small. If so, you must regenerate the kernel and make the value
1965much larger. The default value is reported to be 1024; a value of 32768
1966is said to work. Smaller values may also work.
1967
1968<p>On System V, if you get an error like this,
1969
1970<pre>/usr/local/lib/bison.simple: In function `yyparse':
1971/usr/local/lib/bison.simple:625: virtual memory exhausted
1972</pre>
1973
1974<p>that too indicates a problem with disk space, ulimit, or <code>MAXUMEM</code>.
1975
1976<p>On a System V release 4 system, make sure <code>/usr/bin</code> precedes
1977<code>/usr/ucb</code> in <code>PATH</code>. The <code>cc</code> command in
1978<code>/usr/ucb</code> uses libraries which have bugs.
1979
1980<hr />
1981
1982<h2><a name="TOC93"><a name="vax-dec-ultrix"></a>vax-dec-ultrix</h2>
1983
1984<p>Don't try compiling with VAX C (<code>vcc</code>). It produces incorrect code
1985in some cases (for example, when <code>alloca</code> is used).
1986
1987<hr />
1988
1989<h2><a name="TOC94"><a name="we32k-*-*"></a>we32k-*-*</h2>
1990
1991<p>These computers are also known as the 3b2, 3b5, 3b20 and other similar
1992names. (However, the 3b1 is actually a 68000.)
1993These configurations are obsoleted in GCC 3.1.
1994
1995<p>Don't use <code>-g</code> when compiling with the system's compiler. The
1996system's linker seems to be unable to handle such a large program with
1997debugging information.
1998
1999<p>The system's compiler runs out of capacity when compiling <code>stmt.c</code>
2000in GCC. You can work around this by building <code>cpp</code> in GCC
2001first, then use that instead of the system's preprocessor with the
2002system's C compiler to compile <code>stmt.c</code>. Here is how:
2003
2004<pre>mv /lib/cpp /lib/cpp.att
2005cp cpp /lib/cpp.gnu
2006echo '/lib/cpp.gnu -traditional ${1+"$@"}' &gt; /lib/cpp
2007chmod +x /lib/cpp
2008</pre>
2009
2010<p>The system's compiler produces bad code for some of the GCC
2011optimization files. So you must build the stage 2 compiler without
2012optimization. Then build a stage 3 compiler with optimization.
2013That executable should work. Here are the necessary commands:
2014
2015<pre>make LANGUAGES=c CC=stage1/xgcc CFLAGS="-Bstage1/ -g"
2016make stage2
2017make CC=stage2/xgcc CFLAGS="-Bstage2/ -g -O"
2018</pre>
2019
2020<p>You may need to raise the ULIMIT setting to build a C++ compiler,
2021as the file <code>cc1plus</code> is larger than one megabyte.
2022
2023<hr />
2024
2025<h2><a name="TOC95"><a name="xtensa-*-elf"></a>xtensa-*-elf</h2>
2026
2027<p>This target is intended for embedded Xtensa systems using the
2028<code>newlib</code> C library. It uses ELF but does not support shared
2029objects. Designed-defined instructions specified via the
2030Tensilica Instruction Extension (TIE) language are only supported
2031through inline assembly.
2032
2033<p>The Xtensa configuration information must be specified prior to
2034building GCC. The <code>gcc/config/xtensa/xtensa-config.h</code> header
2035file contains the configuration information. If you created your
2036own Xtensa configuration with the Xtensa Processor Generator, the
2037downloaded files include a customized copy of this header file,
2038which you can use to replace the default header file.
2039
2040<hr />
2041
2042<h2><a name="TOC96"><a name="xtensa-*-linux*"></a>xtensa-*-linux*</h2>
2043
2044<p>This target is for Xtensa systems running GNU/Linux. It supports ELF
2045shared objects and the GNU C library (glibc). It also generates
2046position-independent code (PIC) regardless of whether the
2047<code>-fpic</code> or <code>-fPIC</code> options are used. In other
2048respects, this target is the same as the
2049<a href="#xtensa-*-elf"><code>xtensa-*-elf</code></a> target.
2050
2051<hr />
2052
2053<h2><a name="TOC97"><a name="windows"></a>Microsoft Windows (32-bit)</h2>
2054
2055<p>A port of GCC 2.95.x is included with the
2056<a href="http://www.cygwin.com/">Cygwin environment</a>.
2057
2058<p>Current (as of early 2001) snapshots of GCC will build under Cygwin
2059without modification.
2060
2061<hr />
2062
2063<h2><a name="TOC98"><a name="os2"></a>OS/2</h2>
2064
2065<p>GCC does not currently support OS/2. However, Andrew Zabolotny has been
2066working on a generic OS/2 port with pgcc. The current code can be found
2067at <a href="http://www.goof.com/pcg/os2/">http://www.goof.com/pcg/os2/</a>.
2068
2069<p>An older copy of GCC 2.8.1 is included with the EMX tools available at
2070<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>.
2071
2072<hr />
2073
2074<h2><a name="TOC99"><a name="older"></a>Older systems</h2>
2075
2076<p>GCC contains support files for many older (1980s and early
20771990s) Unix variants. For the most part, support for these systems
2078has not been deliberately removed, but it has not been maintained for
2079several years and may suffer from bitrot. Support from some systems
2080has been removed from GCC 3: fx80, ns32-ns-genix, pyramid, tahoe,
2081gmicro, spur; most of these targets had not been updated since GCC
2082version 1.
2083
2084<p>We are planning to remove support for more older systems, starting in
2085GCC 3.1. Each release will have a list of "obsoleted" systems.
2086Support for these systems is still present in that release, but
2087<code>configure</code> will fail unless the <code>--enable-obsolete</code>
2088option is given. Unless a maintainer steps forward, support for
2089these systems will be removed from the next release of GCC.
2090
2091<p>Support for older systems as targets for cross-compilation is less
2092problematic than support for them as hosts for GCC; if an enthusiast
2093wishes to make such a target work again (including resurrecting any
2094of the targets that never worked with GCC 2, starting from the last
2095CVS version before they were removed), patches
2096<a href="../contribute.html">following the usual requirements</a>
2097would be likely to be accepted, since they should not affect the
2098support for more modern targets.
2099
2100<p>Support for old systems as hosts for GCC can cause problems if the
2101workarounds for compiler, library and operating system bugs affect the
2102cleanliness or maintainability of the rest of GCC. In some cases, to
2103bring GCC up on such a system, if still possible with current GCC, may
2104require first installing an old version of GCC which did work on that
2105system, and using it to compile a more recent GCC, to avoid bugs in
2106the vendor compiler. Old releases of GCC 1 and GCC 2 are available in
2107the <code>old-releases</code> directory on the
2108<a href="../mirrors.html">GCC mirror sites</a>. Header bugs may generally
2109be avoided using <code>fixincludes</code>, but bugs or deficiencies in
2110libraries and the operating system may still cause problems.
2111
2112<p>For some systems, old versions of GNU binutils may also be useful,
2113and are available from <code>pub/binutils/old-releases</code> on
2114<a href="http://sources.redhat.com/mirrors.html">sources.redhat.com mirror sites</a>.
2115
2116<p>Some of the information on specific systems above relates to
2117such older systems, but much of the information
2118about GCC on such systems (which may no longer be applicable to
2119current GCC) is to be found in the GCC texinfo manual.
2120
2121<hr />
2122
2123<h2><a name="TOC100"><a name="elf_targets"></a>all ELF targets (SVR4, Solaris 2, etc.)</h2>
2124
2125<p>C++ support is significantly better on ELF targets if you use the
2126<a href="./configure.html#with-gnu-ld">GNU linker</a>; duplicate copies of
2127inlines, vtables and template instantiations will be discarded
2128automatically.
2129
2130<hr />
2131<p>
2132<a href="./index.html">Return to the GCC Installation page</a>
2133
2134</body></html>
2135
Note: See TracBrowser for help on using the repository browser.