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