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