From 554fd8c5195424bdbcabf5de30fdc183aba391bd Mon Sep 17 00:00:00 2001 From: upstream source tree Date: Sun, 15 Mar 2015 20:14:05 -0400 Subject: obtained gcc-4.6.4.tar.bz2 from upstream website; verified gcc-4.6.4.tar.bz2.sig; imported gcc-4.6.4 source tree from verified upstream tarball. downloading a git-generated archive based on the 'upstream' tag should provide you with a source tree that is binary identical to the one extracted from the above tarball. if you have obtained the source via the command 'git clone', however, do note that line-endings of files in your working directory might differ from line-endings of the respective files in the upstream repository. --- INSTALL/specific.html | 1561 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1561 insertions(+) create mode 100644 INSTALL/specific.html (limited to 'INSTALL/specific.html') diff --git a/INSTALL/specific.html b/INSTALL/specific.html new file mode 100644 index 000000000..11c9bccdd --- /dev/null +++ b/INSTALL/specific.html @@ -0,0 +1,1561 @@ + + +Host/Target specific installation notes for GCC + + + + + + + + + + +

Host/Target specific installation notes for GCC

+ +Please read this document carefully before installing the +GNU Compiler Collection on your machine. + +

Note that this list of install notes is not a list of supported +hosts or targets. Not all supported hosts and targets are listed +here, only the ones that require host-specific or target-specific +information are. + +

+ + + +

+

+ +

alpha*-*-*

+ +

This section contains general configuration information for all +alpha-based platforms using ELF (in particular, ignore this section for +DEC OSF/1, Digital UNIX and Tru64 UNIX). In addition to reading this +section, please read all other sections that match your target. + +

We require binutils 2.11.2 or newer. +Previous binutils releases had a number of problems with DWARF 2 +debugging information, not the least of which is incorrect linking of +shared libraries. + +

+ +

alpha*-dec-osf5.1

+ +

Systems using processors that implement the DEC Alpha architecture and +are running the DEC/Compaq/HP Unix (DEC OSF/1, Digital UNIX, or Compaq/HP +Tru64 UNIX) operating system, for example the DEC Alpha AXP systems. + +

As of GCC 3.2, versions before alpha*-dec-osf4 are no longer +supported. (These are the versions which identify themselves as DEC +OSF/1.) As of GCC 4.6, support for Tru64 UNIX V4.0 and V5.0 has been +removed. + +

On Tru64 UNIX, virtual memory exhausted bootstrap failures +may be fixed by reconfiguring Kernel Virtual Memory and Swap parameters +per the /usr/sbin/sys_check Tuning Suggestions, +or applying the patch in +http://gcc.gnu.org/ml/gcc/2002-08/msg00822.html. Depending on +the OS version used, you need a data segment size between 512 MB and +1 GB, so simply use ulimit -Sd unlimited. + +

As of GNU binutils 2.21, neither GNU as nor GNU ld +are supported on Tru64 UNIX, so you must not configure GCC with +--with-gnu-as or --with-gnu-ld. + +

GCC writes a ‘.verstamp’ directive to the assembler output file +unless it is built as a cross-compiler. It gets the version to use from +the system header file /usr/include/stamp.h. If you install a +new version of Tru64 UNIX, you should rebuild GCC to pick up the new version +stamp. + +

GCC now supports both the native (ECOFF) debugging format used by DBX +and GDB and an encapsulated STABS format for use only with GDB. See the +discussion of the --with-stabs option of configure above +for more information on these formats and how to select them. + + +

There is a bug in DEC's assembler that produces incorrect line numbers +for ECOFF format when the ‘.align’ directive is used. To work +around this problem, GCC will not emit such alignment directives +while writing ECOFF format debugging information even if optimization is +being performed. Unfortunately, this has the very undesirable +side-effect that code addresses when -O is specified are +different depending on whether or not -g is also specified. + +

To avoid this behavior, specify -gstabs+ and use GDB instead of +DBX. DEC is now aware of this problem with the assembler and hopes to +provide a fix shortly. + + +

+ +

arc-*-elf

+ +

Argonaut ARC processor. +This configuration is intended for embedded systems. + +

+ +

arm-*-elf

+ +

ARM-family processors. Subtargets that use the ELF object format +require GNU binutils 2.13 or newer. Such subtargets include: +arm-*-freebsd, arm-*-netbsdelf, arm-*-*linux +and arm-*-rtems. + +

+ +

avr

+ +

ATMEL AVR-family micro controllers. These are used in embedded +applications. There are no standard Unix configurations. +See “AVR Options” in the main manual +for the list of supported MCU types. + +

Use ‘configure --target=avr --enable-languages="c"’ to configure GCC. + +

Further installation notes and other useful information about AVR tools +can also be obtained from: + +

+ +

We strongly recommend using binutils 2.13 or newer. + +

The following error: +

     Error: register required
+
+

indicates that you should upgrade to a newer version of the binutils. + +

+ +

Blackfin

+ +

The Blackfin processor, an Analog Devices DSP. +See “Blackfin Options” in the main manual + +

More information, and a version of binutils with support for this processor, +is available at http://blackfin.uclinux.org + +

+ +

CRIS

+ +

CRIS is the CPU architecture in Axis Communications ETRAX system-on-a-chip +series. These are used in embedded applications. + +

See “CRIS Options” in the main manual +for a list of CRIS-specific options. + +

There are a few different CRIS targets: +

+
cris-axis-elf
Mainly for monolithic embedded systems. Includes a multilib for the +‘v10’ core used in ‘ETRAX 100 LX’. +
cris-axis-linux-gnu
A GNU/Linux port for the CRIS architecture, currently targeting +‘ETRAX 100 LX’ by default. +
+ +

For cris-axis-elf you need binutils 2.11 +or newer. For cris-axis-linux-gnu you need binutils 2.12 or newer. + +

Pre-packaged tools can be obtained from +ftp://ftp.axis.com/pub/axis/tools/cris/compiler-kit/. More +information about this platform is available at +http://developer.axis.com/. + +

+ +

CRX

+ +

The CRX CompactRISC architecture is a low-power 32-bit architecture with +fast context switching and architectural extensibility features. + +

See “CRX Options” in the main manual for a list of CRX-specific options. + +

Use ‘configure --target=crx-elf --enable-languages=c,c++’ to configure +GCC for building a CRX cross-compiler. The option ‘--target=crx-elf’ +is also used to build the ‘newlib’ C library for CRX. + +

It is also possible to build libstdc++-v3 for the CRX architecture. This +needs to be done in a separate step with the following configure settings: + +

     gcc/libstdc++-v3/configure --host=crx-elf --with-newlib \
+         --enable-sjlj-exceptions --enable-cxx-flags='-fexceptions -frtti'
+
+

+ +

DOS

+ +

Please have a look at the binaries page. + +

You cannot install GCC by itself on MSDOS; it will not compile under +any MSDOS compiler except itself. You need to get the complete +compilation package DJGPP, which includes binaries as well as sources, +and includes all the necessary compilation tools and libraries. + +

+ +

*-*-freebsd*

+ +

Support for FreeBSD 1 was discontinued in GCC 3.2. Support for +FreeBSD 2 (and any mutant a.out variants of FreeBSD 3) was +discontinued in GCC 4.0. + +

In order to better utilize FreeBSD base system functionality and match +the configuration of the system compiler, GCC 4.5 and above as well as +GCC 4.4 past 2010-06-20 leverage SSP support in libc (which is present +on FreeBSD 7 or later) and the use of __cxa_atexit by default +(on FreeBSD 6 or later). The use of dl_iterate_phdr inside +libgcc_s.so.1 and boehm-gc (on FreeBSD 7 or later) is enabled +by GCC 4.5 and above. + +

We support FreeBSD using the ELF file format with DWARF 2 debugging +for all CPU architectures. You may use -gstabs instead of +-g, if you really want the old debugging format. There are +no known issues with mixing object files and libraries with different +debugging formats. Otherwise, this release of GCC should now match +more of the configuration used in the stock FreeBSD configuration of +GCC. In particular, --enable-threads is now configured by +default. However, as a general user, do not attempt to replace the +system compiler with this release. Known to bootstrap and check with +good results on FreeBSD 7.2-STABLE. In the past, known to bootstrap +and check with good results on FreeBSD 3.0, 3.4, 4.0, 4.2, 4.3, 4.4, +4.5, 4.8, 4.9 and 5-CURRENT. + +

The version of binutils installed in /usr/bin probably works +with this release of GCC. Bootstrapping against the latest GNU +binutils and/or the version found in /usr/ports/devel/binutils has +been known to enable additional features and improve overall testsuite +results. However, it is currently known that boehm-gc (which itself +is required for java) may not configure properly on FreeBSD prior to +the FreeBSD 7.0 release with GNU binutils after 2.16.1. + +

+ +

h8300-hms

+ +

Renesas H8/300 series of processors. + +

Please have a look at the binaries page. + +

The calling convention and structure layout has changed in release 2.6. +All code must be recompiled. The calling convention now passes the +first three arguments in function calls in registers. Structures are no +longer a multiple of 2 bytes. + +

+ +

hppa*-hp-hpux*

+ +

Support for HP-UX version 9 and older was discontinued in GCC 3.4. + +

We require using gas/binutils on all hppa platforms. Version 2.19 or +later is recommended. + +

It may be helpful to configure GCC with the +--with-gnu-as and +--with-as=... options to ensure that GCC can find GAS. + +

The HP assembler should not be used with GCC. It is rarely tested and may +not work. It shouldn't be used with any languages other than C due to its +many limitations. + +

Specifically, -g does not work (HP-UX uses a peculiar debugging +format which GCC does not know about). It also inserts timestamps +into each object file it creates, causing the 3-stage comparison test to +fail during a bootstrap. You should be able to continue by saying +‘make all-host all-target’ after getting the failure from ‘make’. + +

Various GCC features are not supported. For example, it does not support weak +symbols or alias definitions. As a result, explicit template instantiations +are required when using C++. This makes it difficult if not impossible to +build many C++ applications. + +

There are two default scheduling models for instructions. These are +PROCESSOR_7100LC and PROCESSOR_8000. They are selected from the pa-risc +architecture specified for the target machine when configuring. +PROCESSOR_8000 is the default. PROCESSOR_7100LC is selected when +the target is a ‘hppa1*’ machine. + +

The PROCESSOR_8000 model is not well suited to older processors. Thus, +it is important to completely specify the machine architecture when +configuring if you want a model other than PROCESSOR_8000. The macro +TARGET_SCHED_DEFAULT can be defined in BOOT_CFLAGS if a different +default scheduling model is desired. + +

As of GCC 4.0, GCC uses the UNIX 95 namespace for HP-UX 10.10 +through 11.00, and the UNIX 98 namespace for HP-UX 11.11 and later. +This namespace change might cause problems when bootstrapping with +an earlier version of GCC or the HP compiler as essentially the same +namespace is required for an entire build. This problem can be avoided +in a number of ways. With HP cc, UNIX_STD can be set to ‘95’ +or ‘98’. Another way is to add an appropriate set of predefines +to CC. The description for the munix= option contains +a list of the predefines used with each standard. + +

More specific information to ‘hppa*-hp-hpux*’ targets follows. + +

+ +

hppa*-hp-hpux10

+ +

For hpux10.20, we highly recommend you pick up the latest sed patch +PHCO_19798 from HP. + +

The C++ ABI has changed incompatibly in GCC 4.0. COMDAT subspaces are +used for one-only code and data. This resolves many of the previous +problems in using C++ on this target. However, the ABI is not compatible +with the one implemented under HP-UX 11 using secondary definitions. + +

+ +

hppa*-hp-hpux11

+ +

GCC 3.0 and up support HP-UX 11. GCC 2.95.x is not supported and cannot +be used to compile GCC 3.0 and up. + +

The libffi and libjava libraries haven't been ported to 64-bit HP-UX and don't build. + +

Refer to binaries for information about obtaining +precompiled GCC binaries for HP-UX. Precompiled binaries must be obtained +to build the Ada language as it can't be bootstrapped using C. Ada is +only available for the 32-bit PA-RISC runtime. + +

Starting with GCC 3.4 an ISO C compiler is required to bootstrap. The +bundled compiler supports only traditional C; you will need either HP's +unbundled compiler, or a binary distribution of GCC. + +

It is possible to build GCC 3.3 starting with the bundled HP compiler, +but the process requires several steps. GCC 3.3 can then be used to +build later versions. The fastjar program contains ISO C code and +can't be built with the HP bundled compiler. This problem can be +avoided by not building the Java language. For example, use the +--enable-languages="c,c++,f77,objc" option in your configure +command. + +

There are several possible approaches to building the distribution. +Binutils can be built first using the HP tools. Then, the GCC +distribution can be built. The second approach is to build GCC +first using the HP tools, then build binutils, then rebuild GCC. +There have been problems with various binary distributions, so it +is best not to start from a binary distribution. + +

On 64-bit capable systems, there are two distinct targets. Different +installation prefixes must be used if both are to be installed on +the same system. The ‘hppa[1-2]*-hp-hpux11*’ target generates code +for the 32-bit PA-RISC runtime architecture and uses the HP linker. +The ‘hppa64-hp-hpux11*’ target generates 64-bit code for the +PA-RISC 2.0 architecture. + +

The script config.guess now selects the target type based on the compiler +detected during configuration. You must define PATH or CC so +that configure finds an appropriate compiler for the initial bootstrap. +When CC is used, the definition should contain the options that are +needed whenever CC is used. + +

Specifically, options that determine the runtime architecture must be +in CC to correctly select the target for the build. It is also +convenient to place many other compiler options in CC. For example, +CC="cc -Ac +DA2.0W -Wp,-H16376 -D_CLASSIC_TYPES -D_HPUX_SOURCE" +can be used to bootstrap the GCC 3.3 branch with the HP compiler in +64-bit K&R/bundled mode. The +DA2.0W option will result in +the automatic selection of the ‘hppa64-hp-hpux11*’ target. The +macro definition table of cpp needs to be increased for a successful +build with the HP compiler. _CLASSIC_TYPES and _HPUX_SOURCE need to +be defined when building with the bundled compiler, or when using the +-Ac option. These defines aren't necessary with -Ae. + +

It is best to explicitly configure the ‘hppa64-hp-hpux11*’ target +with the --with-ld=... option. This overrides the standard +search for ld. The two linkers supported on this target require different +commands. The default linker is determined during configuration. As a +result, it's not possible to switch linkers in the middle of a GCC build. +This has been reported to sometimes occur in unified builds of binutils +and GCC. + +

A recent linker patch must be installed for the correct operation of +GCC 3.3 and later. PHSS_26559 and PHSS_24304 are the +oldest linker patches that are known to work. They are for HP-UX +11.00 and 11.11, respectively. PHSS_24303, the companion to +PHSS_24304, might be usable but it hasn't been tested. These +patches have been superseded. Consult the HP patch database to obtain +the currently recommended linker patch for your system. + +

The patches are necessary for the support of weak symbols on the +32-bit port, and for the running of initializers and finalizers. Weak +symbols are implemented using SOM secondary definition symbols. Prior +to HP-UX 11, there are bugs in the linker support for secondary symbols. +The patches correct a problem of linker core dumps creating shared +libraries containing secondary symbols, as well as various other +linking issues involving secondary symbols. + +

GCC 3.3 uses the ELF DT_INIT_ARRAY and DT_FINI_ARRAY capabilities to +run initializers and finalizers on the 64-bit port. The 32-bit port +uses the linker +init and +fini options for the same +purpose. The patches correct various problems with the +init/+fini +options, including program core dumps. Binutils 2.14 corrects a +problem on the 64-bit port resulting from HP's non-standard use of +the .init and .fini sections for array initializers and finalizers. + +

Although the HP and GNU linkers are both supported for the +‘hppa64-hp-hpux11*’ target, it is strongly recommended that the +HP linker be used for link editing on this target. + +

At this time, the GNU linker does not support the creation of long +branch stubs. As a result, it can't successfully link binaries +containing branch offsets larger than 8 megabytes. In addition, +there are problems linking shared libraries, linking executables +with -static, and with dwarf2 unwind and exception support. +It also doesn't provide stubs for internal calls to global functions +in shared libraries, so these calls can't be overloaded. + +

The HP dynamic loader does not support GNU symbol versioning, so symbol +versioning is not supported. It may be necessary to disable symbol +versioning with --disable-symvers when using GNU ld. + +

POSIX threads are the default. The optional DCE thread library is not +supported, so --enable-threads=dce does not work. + +

+ +

*-*-linux-gnu

+ +

Versions of libstdc++-v3 starting with 3.2.1 require bug fixes present +in glibc 2.2.5 and later. More information is available in the +libstdc++-v3 documentation. + +

+ +

i?86-*-linux*

+ +

As of GCC 3.3, binutils 2.13.1 or later is required for this platform. +See bug 10877 for more information. + +

If you receive Signal 11 errors when building on GNU/Linux, then it is +possible you have a hardware problem. Further information on this can be +found on www.bitwizard.nl. + +

+ +

i?86-*-solaris2.[89]

+ +

The Sun assembler in Solaris 8 and 9 has several bugs and limitations. +While GCC works around them, several features are missing, so it is + +recommended to use the GNU assembler instead. There is no bundled +version, but the current version, from GNU binutils 2.21, is known to +work. + +

Solaris 2/x86 doesn't support the execution of SSE/SSE2 instructions +before Solaris 9 4/04, even if the CPU supports them. Programs will +receive SIGILL if they try. The fix is available both in +Solaris 9 Update 6 and kernel patch 112234-12 or newer. There is no +corresponding patch for Solaris 8. To avoid this problem, +-march defaults to ‘pentiumpro’ on Solaris 8 and 9. If +you have the patch installed, you can configure GCC with an appropriate +--with-arch option, but need GNU as for SSE2 support. + +

+ +

i?86-*-solaris2.10

+ +

Use this for Solaris 10 or later on x86 and x86-64 systems. This +configuration is supported by GCC 4.0 and later versions only. Unlike +‘sparcv9-sun-solaris2*’, there is no corresponding 64-bit +configuration like ‘amd64-*-solaris2*’ or ‘x86_64-*-solaris2*’. + + +

It is recommended that you configure GCC to use the GNU assembler, in +/usr/sfw/bin/gas. The versions included in Solaris 10, from GNU +binutils 2.15, and Solaris 11, from GNU binutils 2.19, work fine, +although the current version, from GNU binutils +2.21, is known to work, too. Recent versions of the Sun assembler in +/usr/ccs/bin/as work almost as well, though. + + +

For linking, the Sun linker, is preferred. If you want to use the GNU +linker instead, which is available in /usr/sfw/bin/gld, note that +due to a packaging bug the version in Solaris 10, from GNU binutils +2.15, cannot be used, while the version in Solaris 11, from GNU binutils +2.19, works, as does the latest version, from GNU binutils 2.21. + +

To use GNU as, configure with the options +--with-gnu-as --with-as=/usr/sfw/bin/gas. It may be necessary +to configure with --without-gnu-ld --with-ld=/usr/ccs/bin/ld to +guarantee use of Sun ld. + + +

+ +

ia64-*-linux

+ +

IA-64 processor (also known as IPF, or Itanium Processor Family) +running GNU/Linux. + +

If you are using the installed system libunwind library with +--with-system-libunwind, then you must use libunwind 0.98 or +later. + +

None of the following versions of GCC has an ABI that is compatible +with any of the other versions in this list, with the exception that +Red Hat 2.96 and Trillian 000171 are compatible with each other: +3.1, 3.0.2, 3.0.1, 3.0, Red Hat 2.96, and Trillian 000717. +This primarily affects C++ programs and programs that create shared libraries. +GCC 3.1 or later is recommended for compiling linux, the kernel. +As of version 3.1 GCC is believed to be fully ABI compliant, and hence no +more major ABI changes are expected. + +

+ +

ia64-*-hpux*

+ +

Building GCC on this target requires the GNU Assembler. The bundled HP +assembler will not work. To prevent GCC from using the wrong assembler, +the option --with-gnu-as may be necessary. + +

The GCC libunwind library has not been ported to HPUX. This means that for +GCC versions 3.2.3 and earlier, --enable-libunwind-exceptions +is required to build GCC. For GCC 3.3 and later, this is the default. +For gcc 3.4.3 and later, --enable-libunwind-exceptions is +removed and the system libunwind library will always be used. + +

+ + +

*-ibm-aix*

+ +

Support for AIX version 3 and older was discontinued in GCC 3.4. +Support for AIX version 4.2 and older was discontinued in GCC 4.5. + +

“out of memory” bootstrap failures may indicate a problem with +process resource limits (ulimit). Hard limits are configured in the +/etc/security/limits system configuration file. + +

GCC can bootstrap with recent versions of IBM XLC, but bootstrapping +with an earlier release of GCC is recommended. Bootstrapping with XLC +requires a larger data segment, which can be enabled through the +LDR_CNTRL environment variable, e.g., + +

     % LDR_CNTRL=MAXDATA=0x50000000
+     % export LDR_CNTRL
+
+

One can start with a pre-compiled version of GCC to build from +sources. One may delete GCC's “fixed” header files when starting +with a version of GCC built for an earlier release of AIX. + +

To speed up the configuration phases of bootstrapping and installing GCC, +one may use GNU Bash instead of AIX /bin/sh, e.g., + +

     % CONFIG_SHELL=/opt/freeware/bin/bash
+     % export CONFIG_SHELL
+
+

and then proceed as described in the build instructions, where we strongly recommend specifying an absolute path +to invoke srcdir/configure. + +

Because GCC on AIX is built as a 32-bit executable by default, +(although it can generate 64-bit programs) the GMP and MPFR libraries +required by gfortran must be 32-bit libraries. Building GMP and MPFR +as static archive libraries works better than shared libraries. + +

Errors involving alloca when building GCC generally are due +to an incorrect definition of CC in the Makefile or mixing files +compiled with the native C compiler and GCC. During the stage1 phase of +the build, the native AIX compiler must be invoked as cc +(not xlc). Once configure has been informed of +xlc, one needs to use ‘make distclean’ to remove the +configure cache files and ensure that CC environment variable +does not provide a definition that will confuse configure. +If this error occurs during stage2 or later, then the problem most likely +is the version of Make (see above). + +

The native as and ld are recommended for bootstrapping +on AIX. The GNU Assembler, GNU Linker, and GNU Binutils version 2.20 +is required to bootstrap on AIX 5. The native AIX tools do +interoperate with GCC. + +

Building libstdc++.a requires a fix for an AIX Assembler bug +APAR IY26685 (AIX 4.3) or APAR IY25528 (AIX 5.1). It also requires a +fix for another AIX Assembler bug and a co-dependent AIX Archiver fix +referenced as APAR IY53606 (AIX 5.2) or as APAR IY54774 (AIX 5.1) + +

‘libstdc++’ in GCC 3.4 increments the major version number of the +shared object and GCC installation places the libstdc++.a +shared library in a common location which will overwrite the and GCC +3.3 version of the shared library. Applications either need to be +re-linked against the new shared library or the GCC 3.1 and GCC 3.3 +versions of the ‘libstdc++’ shared object needs to be available +to the AIX runtime loader. The GCC 3.1 ‘libstdc++.so.4’, if +present, and GCC 3.3 ‘libstdc++.so.5’ shared objects can be +installed for runtime dynamic loading using the following steps to set +the ‘F_LOADONLY’ flag in the shared object for each +multilib libstdc++.a installed: + +

Extract the shared objects from the currently installed +libstdc++.a archive: +

     % ar -x libstdc++.a libstdc++.so.4 libstdc++.so.5
+
+

Enable the ‘F_LOADONLY’ flag so that the shared object will be +available for runtime dynamic loading, but not linking: +

     % strip -e libstdc++.so.4 libstdc++.so.5
+
+

Archive the runtime-only shared object in the GCC 3.4 +libstdc++.a archive: +

     % ar -q libstdc++.a libstdc++.so.4 libstdc++.so.5
+
+

Linking executables and shared libraries may produce warnings of +duplicate symbols. The assembly files generated by GCC for AIX always +have included multiple symbol definitions for certain global variable +and function declarations in the original program. The warnings should +not prevent the linker from producing a correct library or runnable +executable. + +

AIX 4.3 utilizes a “large format” archive to support both 32-bit and +64-bit object modules. The routines provided in AIX 4.3.0 and AIX 4.3.1 +to parse archive libraries did not handle the new format correctly. +These routines are used by GCC and result in error messages during +linking such as “not a COFF file”. The version of the routines shipped +with AIX 4.3.1 should work for a 32-bit environment. The -g +option of the archive command may be used to create archives of 32-bit +objects using the original “small format”. A correct version of the +routines is shipped with AIX 4.3.2 and above. + +

Some versions of the AIX binder (linker) can fail with a relocation +overflow severe error when the -bbigtoc option is used to link +GCC-produced object files into an executable that overflows the TOC. A fix +for APAR IX75823 (OVERFLOW DURING LINK WHEN USING GCC AND -BBIGTOC) is +available from IBM Customer Support and from its +techsupport.services.ibm.com +website as PTF U455193. + +

The AIX 4.3.2.1 linker (bos.rte.bind_cmds Level 4.3.2.1) will dump core +with a segmentation fault when invoked by any version of GCC. A fix for +APAR IX87327 is available from IBM Customer Support and from its +techsupport.services.ibm.com +website as PTF U461879. This fix is incorporated in AIX 4.3.3 and above. + +

The initial assembler shipped with AIX 4.3.0 generates incorrect object +files. A fix for APAR IX74254 (64BIT DISASSEMBLED OUTPUT FROM COMPILER FAILS +TO ASSEMBLE/BIND) is available from IBM Customer Support and from its +techsupport.services.ibm.com +website as PTF U453956. This fix is incorporated in AIX 4.3.1 and above. + +

AIX provides National Language Support (NLS). Compilers and assemblers +use NLS to support locale-specific representations of various data +formats including floating-point numbers (e.g., ‘.’ vs ‘,’ for +separating decimal fractions). There have been problems reported where +GCC does not produce the same floating-point formats that the assembler +expects. If one encounters this problem, set the LANG +environment variable to ‘C’ or ‘En_US’. + +

A default can be specified with the -mcpu=cpu_type +switch and using the configure option --with-cpu-cpu_type. + +

+ +

iq2000-*-elf

+ +

Vitesse IQ2000 processors. These are used in embedded +applications. There are no standard Unix configurations. + +

+ +

lm32-*-elf

+ +

Lattice Mico32 processor. +This configuration is intended for embedded systems. + +

+ +

lm32-*-uclinux

+ +

Lattice Mico32 processor. +This configuration is intended for embedded systems running uClinux. + +

+ +

m32c-*-elf

+ +

Renesas M32C processor. +This configuration is intended for embedded systems. + +

+ +

m32r-*-elf

+ +

Renesas M32R processor. +This configuration is intended for embedded systems. + +

+ +

m6811-elf

+ +

Motorola 68HC11 family micro controllers. These are used in embedded +applications. There are no standard Unix configurations. + +

+ +

m6812-elf

+ +

Motorola 68HC12 family micro controllers. These are used in embedded +applications. There are no standard Unix configurations. + +

+ +

m68k-*-*

+ +

By default, +‘m68k-*-elf*’, ‘m68k-*-rtems’, ‘m68k-*-uclinux’ and +‘m68k-*-linux’ +build libraries for both M680x0 and ColdFire processors. If you only +need the M680x0 libraries, you can omit the ColdFire ones by passing +--with-arch=m68k to configure. Alternatively, you +can omit the M680x0 libraries by passing --with-arch=cf to +configure. These targets default to 5206 or 5475 code as +appropriate for the target system when +configured with --with-arch=cf and 68020 code otherwise. + +

The ‘m68k-*-netbsd’ and +‘m68k-*-openbsd’ targets also support the --with-arch +option. They will generate ColdFire CFV4e code when configured with +--with-arch=cf and 68020 code otherwise. + +

You can override the default processors listed above by configuring +with --with-cpu=target. This target can either +be a -mcpu argument or one of the following values: +‘m68000’, ‘m68010’, ‘m68020’, ‘m68030’, +‘m68040’, ‘m68060’, ‘m68020-40’ and ‘m68020-60’. + +

+ +

m68k-*-uclinux

+ +

GCC 4.3 changed the uClinux configuration so that it uses the +‘m68k-linux-gnu’ ABI rather than the ‘m68k-elf’ ABI. +It also added improved support for C++ and flat shared libraries, +both of which were ABI changes. However, you can still use the +original ABI by configuring for ‘m68k-uclinuxoldabi’ or +‘m68k-vendor-uclinuxoldabi’. + +

+ +

mep-*-elf

+ +

Toshiba Media embedded Processor. +This configuration is intended for embedded systems. + +

+ +

microblaze-*-elf

+ +

Xilinx MicroBlaze processor. +This configuration is intended for embedded systems. + +

+ +

mips-*-*

+ +

If on a MIPS system you get an error message saying “does not have gp +sections for all it's [sic] sectons [sic]”, don't worry about it. This +happens whenever you use GAS with the MIPS linker, but there is not +really anything wrong, and it is okay to use the output file. You can +stop such warnings by installing the GNU linker. + +

It would be nice to extend GAS to produce the gp tables, but they are +optional, and there should not be a warning about their absence. + +

The libstdc++ atomic locking routines for MIPS targets requires MIPS II +and later. A patch went in just after the GCC 3.3 release to +make ‘mips*-*-*’ use the generic implementation instead. You can also +configure for ‘mipsel-elf’ as a workaround. The +‘mips*-*-linux*’ target continues to use the MIPS II routines. More +work on this is expected in future releases. + + + +

The built-in __sync_* functions are available on MIPS II and +later systems and others that support the ‘ll’, ‘sc’ and +‘sync’ instructions. This can be overridden by passing +--with-llsc or --without-llsc when configuring GCC. +Since the Linux kernel emulates these instructions if they are +missing, the default for ‘mips*-*-linux*’ targets is +--with-llsc. The --with-llsc and +--without-llsc configure options may be overridden at compile +time by passing the -mllsc or -mno-llsc options to +the compiler. + +

MIPS systems check for division by zero (unless +-mno-check-zero-division is passed to the compiler) by +generating either a conditional trap or a break instruction. Using +trap results in smaller code, but is only supported on MIPS II and +later. Also, some versions of the Linux kernel have a bug that +prevents trap from generating the proper signal (SIGFPE). To enable +the use of break, use the --with-divide=breaks +configure option when configuring GCC. The default is to +use traps on systems that support them. + +

Cross-compilers for the MIPS as target using the MIPS assembler +currently do not work, because the auxiliary programs +mips-tdump.c and mips-tfile.c can't be compiled on +anything but a MIPS. It does work to cross compile for a MIPS +if you use the GNU assembler and linker. + +

The assembler from GNU binutils 2.17 and earlier has a bug in the way +it sorts relocations for REL targets (o32, o64, EABI). This can cause +bad code to be generated for simple C++ programs. Also the linker +from GNU binutils versions prior to 2.17 has a bug which causes the +runtime linker stubs in very large programs, like libgcj.so, to +be incorrectly generated. GNU Binutils 2.18 and later (and snapshots +made after Nov. 9, 2006) should be free from both of these problems. + +

+ +

mips-sgi-irix5

+ +

Support for IRIX 5 has been removed in GCC 4.6. + +

+ +

mips-sgi-irix6

+ +

Support for IRIX 6 releases before 6.5 has been removed in GCC 4.6, as +well as support for +the O32 ABI. It is strongly recommended to upgrade to at least +IRIX 6.5.18. This release introduced full ISO C99 support, though for +the N32 and N64 ABIs only. + +

To build and use GCC on IRIX 6.5, you need the IRIX Development Foundation +(IDF) and IRIX Development Libraries (IDL). They are included with the +IRIX 6.5 media. + +

If you are using SGI's MIPSpro cc as your bootstrap compiler, you must +ensure that the N32 ABI is in use. To test this, compile a simple C +file with cc and then run file on the +resulting object file. The output should look like: + +

     test.o: ELF N32 MSB ...
+
+

If you see: + +

     test.o: ELF 32-bit MSB ...
+
+

or + +

     test.o: ELF 64-bit MSB ...
+
+

then your version of cc uses the O32 or N64 ABI by default. You +should set the environment variable CC to ‘cc -n32’ +before configuring GCC. + +

If you want the resulting gcc to run on old 32-bit systems +with the MIPS R4400 CPU, you need to ensure that only code for the ‘mips3’ +instruction set architecture (ISA) is generated. While GCC 3.x does +this correctly, both GCC 2.95 and SGI's MIPSpro cc may change +the ISA depending on the machine where GCC is built. Using one of them +as the bootstrap compiler may result in ‘mips4’ code, which won't run at +all on ‘mips3’-only systems. For the test program above, you should see: + +

     test.o: ELF N32 MSB mips-3 ...
+
+

If you get: + +

     test.o: ELF N32 MSB mips-4 ...
+
+

instead, you should set the environment variable CC to ‘cc +-n32 -mips3’ or ‘gcc -mips3’ respectively before configuring GCC. + +

MIPSpro C 7.4 may cause bootstrap failures, due to a bug when inlining +memcmp. Either add -U__INLINE_INTRINSICS to the CC +environment variable as a workaround or upgrade to MIPSpro C 7.4.1m. + +

GCC on IRIX 6.5 is usually built to support the N32 and N64 ABIs. If +you build GCC on a system that doesn't have the N64 libraries installed +or cannot run 64-bit binaries, +you need to configure with --disable-multilib so GCC doesn't +try to use them. +Look for /usr/lib64/libc.so.1 to see if you +have the 64-bit libraries installed. + +

GCC must be configured with GNU as. The latest version, from GNU +binutils 2.21, is known to work. On the other hand, bootstrap fails +with GNU ld at least since GNU binutils 2.17. + +

The --enable-libgcj +option is disabled by default: IRIX 6 uses a very low default limit +(20480) for the command line length. Although libtool contains a +workaround for this problem, at least the N64 ‘libgcj’ is known not +to build despite this, running into an internal error of the native +ld. A sure fix is to increase this limit (‘ncargs’) to +its maximum of 262144 bytes. If you have root access, you can use the +systune command to do this. + + +

wchar_t support in ‘libstdc++’ is not available for old +IRIX 6.5.x releases, x < 19. The problem cannot be autodetected +and in order to build GCC for such targets you need to configure with +--disable-wchar_t. + +

+ +

moxie-*-elf

+ +

The moxie processor. See http://moxielogic.org/ for more +information about this processor. + +

+ +

powerpc-*-*

+ +

You can specify a default version for the -mcpu=cpu_type +switch by using the configure option --with-cpu-cpu_type. + +

You will need +binutils 2.15 +or newer for a working GCC. + +

+ +

powerpc-*-darwin*

+ +

PowerPC running Darwin (Mac OS X kernel). + +

Pre-installed versions of Mac OS X may not include any developer tools, +meaning that you will not be able to build GCC from source. Tool +binaries are available at +http://opensource.apple.com/. + +

This version of GCC requires at least cctools-590.36. The +cctools-590.36 package referenced from +http://gcc.gnu.org/ml/gcc/2006-03/msg00507.html will not work +on systems older than 10.3.9 (aka darwin7.9.0). + +

+ +

powerpc-*-elf

+ +

PowerPC system in big endian mode, running System V.4. + +

+ +

powerpc*-*-linux-gnu*

+ +

PowerPC system in big endian mode running Linux. + +

+ +

powerpc-*-netbsd*

+ +

PowerPC system in big endian mode running NetBSD. + +

+ +

powerpc-*-eabisim

+ +

Embedded PowerPC system in big endian mode for use in running under the +PSIM simulator. + +

+ +

powerpc-*-eabi

+ +

Embedded PowerPC system in big endian mode. + +

+ +

powerpcle-*-elf

+ +

PowerPC system in little endian mode, running System V.4. + +

+ +

powerpcle-*-eabisim

+ +

Embedded PowerPC system in little endian mode for use in running under +the PSIM simulator. + +

+ +

powerpcle-*-eabi

+ +

Embedded PowerPC system in little endian mode. + +

+ +

rx-*-elf

+ +

The Renesas RX processor. See +http://eu.renesas.com/fmwk.jsp?cnt=rx600_series_landing.jsp&fp=/products/mpumcu/rx_family/rx600_series +for more information about this processor. + +

+ +

s390-*-linux*

+ +

S/390 system running GNU/Linux for S/390. + +

+ +

s390x-*-linux*

+ +

zSeries system (64-bit) running GNU/Linux for zSeries. + +

+ +

s390x-ibm-tpf*

+ +

zSeries system (64-bit) running TPF. This platform is +supported as cross-compilation target only. + +

+ + + + +

*-*-solaris2*

+ +

Support for Solaris 7 has been removed in GCC 4.6. + +

Sun does not ship a C compiler with Solaris 2, though you can download +the Sun Studio compilers for free. Alternatively, +you can install a pre-built GCC to bootstrap and install GCC. See the +binaries page for details. + +

The Solaris 2 /bin/sh will often fail to configure +‘libstdc++-v3’, ‘boehm-gc’ or ‘libjava’. We therefore +recommend using the following initial sequence of commands + +

     % CONFIG_SHELL=/bin/ksh
+     % export CONFIG_SHELL
+
+

and proceed as described in the configure instructions. +In addition we strongly recommend specifying an absolute path to invoke +srcdir/configure. + +

Solaris 2 comes with a number of optional OS packages. Some of these +are needed to use GCC fully, namely SUNWarc, +SUNWbtool, SUNWesu, SUNWhea, SUNWlibm, +SUNWsprot, and SUNWtoo. If you did not install all +optional packages when installing Solaris 2, you will need to verify that +the packages that GCC needs are installed. + +

To check whether an optional package is installed, use +the pkginfo command. To add an optional package, use the +pkgadd command. For further details, see the Solaris 2 +documentation. + +

Trying to use the linker and other tools in +/usr/ucb to install GCC has been observed to cause trouble. +For example, the linker may hang indefinitely. The fix is to remove +/usr/ucb from your PATH. + +

The build process works more smoothly with the legacy Sun tools so, if you +have /usr/xpg4/bin in your PATH, we recommend that you place +/usr/bin before /usr/xpg4/bin for the duration of the build. + +

We recommend the use of the Sun assembler or the GNU assembler, in +conjunction with the Sun linker. The GNU as +versions included in Solaris 10, from GNU binutils 2.15, and Solaris 11, +from GNU binutils 2.19, are known to work. They can be found in +/usr/sfw/bin/gas. Current versions of GNU binutils (2.21) +are known to work as well. Note that your mileage may vary +if you use a combination of the GNU tools and the Sun tools: while the +combination GNU as + Sun ld should reasonably work, +the reverse combination Sun as + GNU ld is known to +cause memory corruption at runtime in some cases for C++ programs. + +GNU ld usually works as well, although the version included in +Solaris 10 cannot be used due to several bugs. Again, the current +version (2.21) is known to work, but generally lacks platform specific +features, so better stay with Sun ld. + +

To enable symbol versioning in ‘libstdc++’ with Sun ld, +you need to have any version of GNU c++filt, which is part of +GNU binutils. ‘libstdc++’ symbol versioning will be disabled if no +appropriate version is found. Sun c++filt from the Sun Studio +compilers does not work. + +

Sun bug 4296832 turns up when compiling X11 headers with GCC 2.95 or +newer: g++ will complain that types are missing. These headers +assume that omitting the type means int; this assumption worked for +C90 but is wrong for C++, and is now wrong for C99 also. + +

g++ accepts such (invalid) constructs with the option +-fpermissive; it will assume that any missing type is int +(as defined by C90). + +

There are patches for Solaris 8 (108652-24 or newer for SPARC, +108653-22 for Intel) that fix this bug. + +

Sun bug 4927647 sometimes causes random spurious testsuite failures +related to missing diagnostic output. This bug doesn't affect GCC +itself, rather it is a kernel bug triggered by the expect +program which is used only by the GCC testsuite driver. When the bug +causes the expect program to miss anticipated output, extra +testsuite failures appear. + +

There are patches for Solaris 8 (117350-12 or newer for SPARC, +117351-12 or newer for Intel) and Solaris 9 (117171-11 or newer for +SPARC, 117172-11 or newer for Intel) that address this problem. + +

Solaris 8 provides an alternate implementation of the thread libraries, +‘libpthread’ and ‘libthread’. They are required for TLS +support and have been made the default in Solaris 9, so they are always +used on Solaris 8. + +

Thread-local storage (TLS) is supported in Solaris 8 and 9, but requires +some patches. The ‘libthread’ patches provide the +__tls_get_addr (SPARC, 64-bit x86) resp. ___tls_get_addr +(32-bit x86) functions. On Solaris 8, you need 108993-26 or newer on +SPARC, 108994-26 or newer on Intel. On Solaris 9, the necessary support +on SPARC is present since FCS, while 114432-05 or newer is required on +Intel. Additionally, on Solaris 8, patch 109147-14 or newer on SPARC or +109148-22 or newer on Intel are required for the Sun ld and +runtime linker (ld.so.1) support. Again, Solaris 9/SPARC +works since FCS, while 113986-02 is required on Intel. The linker +patches must be installed even if GNU ld is used. Sun +as in Solaris 8 and 9 doesn't support the necessary +relocations, so GNU as must be used. The configure +script checks for those prerequisites and automatically enables TLS +support if they are met. Although those minimal patch versions should +work, it is recommended to use the latest patch versions which include +additional bug fixes. + +

+ +

sparc*-*-*

+ +

This section contains general configuration information for all +SPARC-based platforms. In addition to reading this section, please +read all other sections that match your target. + +

Newer versions of the GNU Multiple Precision Library (GMP), the MPFR +library and the MPC library are known to be miscompiled by earlier +versions of GCC on these platforms. We therefore recommend the use +of the exact versions of these libraries listed as minimal versions +in the prerequisites. + +

+ +

sparc-sun-solaris2*

+ +

When GCC is configured to use GNU binutils 2.14 or later, the binaries +produced are smaller than the ones produced using Sun's native tools; +this difference is quite significant for binaries containing debugging +information. + +

Starting with Solaris 7, the operating system is capable of executing +64-bit SPARC V9 binaries. GCC 3.1 and later properly supports +this; the -m64 option enables 64-bit code generation. +However, if all you want is code tuned for the UltraSPARC CPU, you +should try the -mtune=ultrasparc option instead, which produces +code that, unlike full 64-bit code, can still run on non-UltraSPARC +machines. + +

When configuring on a Solaris 7 or later system that is running a kernel +that supports only 32-bit binaries, one must configure with +--disable-multilib, since we will not be able to build the +64-bit target libraries. + +

GCC 3.3 and GCC 3.4 trigger code generation bugs in earlier versions of +the GNU compiler (especially GCC 3.0.x versions), which lead to the +miscompilation of the stage1 compiler and the subsequent failure of the +bootstrap process. A workaround is to use GCC 3.2.3 as an intermediary +stage, i.e. to bootstrap that compiler with the base compiler and then +use it to bootstrap the final compiler. + +

GCC 3.4 triggers a code generation bug in versions 5.4 (Sun ONE Studio 7) +and 5.5 (Sun ONE Studio 8) of the Sun compiler, which causes a bootstrap +failure in form of a miscompilation of the stage1 compiler by the Sun +compiler. This is Sun bug 4974440. This is fixed with patch 112760-07. + +

GCC 3.4 changed the default debugging format from Stabs to DWARF-2 for +32-bit code on Solaris 7 and later. If you use the Sun assembler, this +change apparently runs afoul of Sun bug 4910101 (which is referenced as +an x86-only problem by Sun, probably because they do not use DWARF-2). +A symptom of the problem is that you cannot compile C++ programs like +groff 1.19.1 without getting messages similar to the following: + +

     ld: warning: relocation error: R_SPARC_UA32: ...
+       external symbolic relocation against non-allocatable section
+       .debug_info cannot be processed at runtime: relocation ignored.
+
+

To work around this problem, compile with -gstabs+ instead of +plain -g. + +

When configuring the GNU Multiple Precision Library (GMP), the MPFR +library or the MPC library on a Solaris 7 or later system, the canonical +target triplet must be specified as the build parameter on the +configure line. This target triplet can be obtained by invoking ./config.guess in the toplevel source directory of GCC (and +not that of GMP or MPFR or MPC). For example on a Solaris 9 system: + +

     % ./configure --build=sparc-sun-solaris2.9 --prefix=xxx
+
+

+ +

sparc-sun-solaris2.10

+ +

There is a bug in older versions of the Sun assembler which breaks +thread-local storage (TLS). A typical error message is + +

     ld: fatal: relocation error: R_SPARC_TLS_LE_HIX22: file /var/tmp//ccamPA1v.o:
+       symbol <unknown>: bad symbol type SECT: symbol type must be TLS
+
+

This bug is fixed in Sun patch 118683-03 or later. + +

+ +

sparc-*-linux*

+ +

GCC versions 3.0 and higher require binutils 2.11.2 and glibc 2.2.4 +or newer on this platform. All earlier binutils and glibc +releases mishandled unaligned relocations on sparc-*-* targets. + +

+ +

sparc64-*-solaris2*

+ +

When configuring the GNU Multiple Precision Library (GMP), the MPFR +library or the MPC library, the canonical target triplet must be specified +as the build parameter on the configure line. For example +on a Solaris 9 system: + +

     % ./configure --build=sparc64-sun-solaris2.9 --prefix=xxx
+
+

The following compiler flags must be specified in the configure +step in order to bootstrap this target with the Sun compiler: + +

     % CC="cc -xarch=v9 -xildoff" srcdir/configure [options] [target]
+
+

-xarch=v9 specifies the SPARC-V9 architecture to the Sun toolchain +and -xildoff turns off the incremental linker. + +

+ +

sparcv9-*-solaris2*

+ +

This is a synonym for ‘sparc64-*-solaris2*’. + +

+ +

*-*-vxworks*

+ +

Support for VxWorks is in flux. At present GCC supports only the +very recent VxWorks 5.5 (aka Tornado 2.2) release, and only on PowerPC. +We welcome patches for other architectures supported by VxWorks 5.5. +Support for VxWorks AE would also be welcome; we believe this is merely +a matter of writing an appropriate “configlette” (see below). We are +not interested in supporting older, a.out or COFF-based, versions of +VxWorks in GCC 3. + +

VxWorks comes with an older version of GCC installed in +$WIND_BASE/host; we recommend you do not overwrite it. +Choose an installation prefix entirely outside $WIND_BASE. +Before running configure, create the directories prefix +and prefix/bin. Link or copy the appropriate assembler, +linker, etc. into prefix/bin, and set your PATH to +include that directory while running both configure and +make. + +

You must give configure the +--with-headers=$WIND_BASE/target/h switch so that it can +find the VxWorks system headers. Since VxWorks is a cross compilation +target only, you must also specify --target=target. +configure will attempt to create the directory +prefix/target/sys-include and copy files into it; +make sure the user running configure has sufficient privilege +to do so. + +

GCC's exception handling runtime requires a special “configlette” +module, contrib/gthr_supp_vxw_5x.c. Follow the instructions in +that file to add the module to your kernel build. (Future versions of +VxWorks will incorporate this module.) + +

+ +

x86_64-*-*, amd64-*-*

+ +

GCC supports the x86-64 architecture implemented by the AMD64 processor +(amd64-*-* is an alias for x86_64-*-*) on GNU/Linux, FreeBSD and NetBSD. +On GNU/Linux the default is a bi-arch compiler which is able to generate +both 64-bit x86-64 and 32-bit x86 code (via the -m32 switch). + +

+ +

xtensa*-*-elf

+ +

This target is intended for embedded Xtensa systems using the +‘newlib’ C library. It uses ELF but does not support shared +objects. Designed-defined instructions specified via the +Tensilica Instruction Extension (TIE) language are only supported +through inline assembly. + +

The Xtensa configuration information must be specified prior to +building GCC. The include/xtensa-config.h header +file contains the configuration information. If you created your +own Xtensa configuration with the Xtensa Processor Generator, the +downloaded files include a customized copy of this header file, +which you can use to replace the default header file. + +

+ +

xtensa*-*-linux*

+ +

This target is for Xtensa systems running GNU/Linux. It supports ELF +shared objects and the GNU C library (glibc). It also generates +position-independent code (PIC) regardless of whether the +-fpic or -fPIC options are used. In other +respects, this target is the same as the +‘xtensa*-*-elf’ target. + +

+ +

Microsoft Windows

+ +

Intel 16-bit versions

+ +

The 16-bit versions of Microsoft Windows, such as Windows 3.1, are not +supported. + +

However, the 32-bit port has limited support for Microsoft +Windows 3.11 in the Win32s environment, as a target only. See below. + +

Intel 32-bit versions

+ +

The 32-bit versions of Windows, including Windows 95, Windows NT, Windows +XP, and Windows Vista, are supported by several different target +platforms. These targets differ in which Windows subsystem they target +and which C libraries are used. + +

+ +

Intel 64-bit versions

+ +

GCC contains support for x86-64 using the mingw-w64 +runtime library, available from http://mingw-w64.sourceforge.net/. +This library should be used with the target triple x86_64-pc-mingw32. + +

Presently Windows for Itanium is not supported. + +

Windows CE

+ +

Windows CE is supported as a target only on ARM (arm-wince-pe), Hitachi +SuperH (sh-wince-pe), and MIPS (mips-wince-pe). + +

Other Windows Platforms

+ +

GCC no longer supports Windows NT on the Alpha or PowerPC. + +

GCC no longer supports the Windows POSIX subsystem. However, it does +support the Interix subsystem. See above. + +

Old target names including *-*-winnt and *-*-windowsnt are no longer used. + +

PW32 (i386-pc-pw32) support was never completed, and the project seems to +be inactive. See http://pw32.sourceforge.net/ for more information. + +

UWIN support has been removed due to a lack of maintenance. + +

+ +

*-*-cygwin

+ +

Ports of GCC are included with the +Cygwin environment. + +

GCC will build under Cygwin without modification; it does not build +with Microsoft's C++ compiler and there are no plans to make it do so. + +

The Cygwin native compiler can be configured to target any 32-bit x86 +cpu architecture desired; the default is i686-pc-cygwin. It should be +used with as up-to-date a version of binutils as possible; use either +the latest official GNU binutils release in the Cygwin distribution, +or version 2.20 or above if building your own. + +

+ +

*-*-interix

+ +

The Interix target is used by OpenNT, Interix, Services For UNIX (SFU), +and Subsystem for UNIX-based Applications (SUA). Applications compiled +with this target run in the Interix subsystem, which is separate from +the Win32 subsystem. This target was last known to work in GCC 3.3. + +

+ +

*-*-mingw32

+ +

GCC will build with and support only MinGW runtime 3.12 and later. +Earlier versions of headers are incompatible with the new default semantics +of extern inline in -std=c99 and -std=gnu99 modes. + +

+ +

Older systems

+ +

GCC contains support files for many older (1980s and early +1990s) Unix variants. For the most part, support for these systems +has not been deliberately removed, but it has not been maintained for +several years and may suffer from bitrot. + +

Starting with GCC 3.1, each release has a list of “obsoleted” systems. +Support for these systems is still present in that release, but +configure will fail unless the --enable-obsolete +option is given. Unless a maintainer steps forward, support for these +systems will be removed from the next release of GCC. + +

Support for old systems as hosts for GCC can cause problems if the +workarounds for compiler, library and operating system bugs affect the +cleanliness or maintainability of the rest of GCC. In some cases, to +bring GCC up on such a system, if still possible with current GCC, may +require first installing an old version of GCC which did work on that +system, and using it to compile a more recent GCC, to avoid bugs in the +vendor compiler. Old releases of GCC 1 and GCC 2 are available in the +old-releases directory on the GCC mirror sites. Header bugs may generally be avoided using +fixincludes, but bugs or deficiencies in libraries and the +operating system may still cause problems. + +

Support for older systems as targets for cross-compilation is less +problematic than support for them as hosts for GCC; if an enthusiast +wishes to make such a target work again (including resurrecting any of +the targets that never worked with GCC 2, starting from the last +version before they were removed), patches +following the usual requirements would be +likely to be accepted, since they should not affect the support for more +modern targets. + +

For some systems, old versions of GNU binutils may also be useful, +and are available from pub/binutils/old-releases on +sourceware.org mirror sites. + +

Some of the information on specific systems above relates to +such older systems, but much of the information +about GCC on such systems (which may no longer be applicable to +current GCC) is to be found in the GCC texinfo manual. + +

+ +

all ELF targets (SVR4, Solaris 2, etc.)

+ +

C++ support is significantly better on ELF targets if you use the +GNU linker; duplicate copies of +inlines, vtables and template instantiations will be discarded +automatically. + +

+

Return to the GCC Installation page + + + + + + + -- cgit v1.2.3