@heading Tools/packages necessary for modifying GCC
@table @asis
-@item autoconf versions 2.13 and 2.57
+@item autoconf versions 2.13 and 2.59
@itemx GNU m4 version 1.4 (or later)
Necessary when modifying @file{configure.in}, @file{aclocal.m4}, etc.@:
to regenerate @file{configure} and @file{config.in} files. Most
directories require autoconf 2.13 (exactly), but @file{libiberty},
@file{fastjar}, @file{libstdc++-v3}, @file{libjava/libltdl}, @file{boehm-gc},
-and @file{gcc} require autoconf 2.57 (exactly).
+@file{intl}, @file{libada}, @file{libffi} and @file{gcc} require autoconf
+2.59 (exactly).
@item automake versions 1.4-gcj and 1.7.9
@file{libf2c}, @file{libiberty}, @file{libobjc} directories as well as any
of their subdirectories.
-The @file{libstdc++-v3}, @file{libjava/libltdl}, and @file{fastjar}
-directories require automake 1.7.9. However, the Java directories, which
-include @file{boehm-gc}, @file{libffi}, @file{libjava}, and @file{zlib},
+The @file{libstdc++-v3}, @file{libjava/libltdl}, @file{fastjar} and
+@file{libffi} directories require automake 1.7.9. However, the Java
+directories, which include @file{boehm-gc}, @file{libjava}, and @file{zlib},
require a modified version of automake 1.4 downloadable from
@uref{ftp://gcc.gnu.org/pub/java/automake-gcj-1.4.tar.gz}.
@end html
@heading @anchor{*-*-freebsd*}*-*-freebsd*
-The version of binutils installed in @file{/usr/bin} is known to work unless
-otherwise specified in any per-architecture notes. However, binutils
-2.12.1 or greater is known to improve overall testsuite results.
+The version of binutils installed in @file{/usr/bin} probably works with
+this release of GCC. However, on FreeBSD 4, bootstrapping against the
+latest FSF binutils is known to improve overall testsuite results; and,
+on FreeBSD/alpha, using binutils 2.14 or later is required to build libjava.
Support for FreeBSD 1 was discontinued in GCC 3.2.
+Support for FreeBSD 2 will be discontinued after GCC 3.4. The
+following was true for GCC 3.1 but the current status is unknown.
For FreeBSD 2 or any mutant a.out versions of FreeBSD 3: All
configuration support and files as shipped with GCC 2.95 are still in
place. FreeBSD 2.2.7 has been known to bootstrap completely; however,
particular, @option{--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 4.8-STABLE and 5-CURRENT@. In the past, known to
+results on FreeBSD 4.9-STABLE and 5-CURRENT@. 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-STABLE@.
+4.3, 4.4, 4.5, 4.8-STABLE@.
In principle, @option{--enable-threads} is now compatible with
@option{--enable-libgcj} on FreeBSD@. However, it has only been built
AIX Make frequently has problems with GCC makefiles. GNU Make 3.79.1 or
newer is recommended to build on this platform.
+To speed up the configuration phases of bootstrapping and installing GCC,
+one may use GNU Bash instead of AIX @command{/bin/sh}, e.g.,
+
+@smallexample
+ % CONFIG_SHELL=/opt/freeware/bin/bash
+ % export CONFIG_SHELL
+@end smallexample
+
+and then proceed as described in @uref{build.html,,the build instructions},
+where we strongly recommend using GNU make and specifying an absolute path
+to invoke @var{srcdir}/configure.
+
Errors involving @code{alloca} when building GCC generally are due
to an incorrect definition of @code{CC} in the Makefile or mixing files
compiled with the native C compiler and GCC@. During the stage1 phase of
The native AIX tools do interoperate with GCC@.
Building @file{libstdc++.a} requires a fix for an AIX Assembler bug
-APAR IY26685 (AIX 4.3) or APAR IY25528 (AIX 5.1).
+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 a APAR TBD (AIX 5.1)
-@samp{libstdc++} in GCC 3.2 increments the major version number of the
+@samp{libstdc++} in GCC 3.4 increments the major version number of the
shared object and GCC installation places the @file{libstdc++.a}
-shared library in a common location which will overwrite the GCC 3.1
-version of the shared library. Applications either need to be
-re-linked against the new shared library or the GCC 3.1 version of the
-@samp{libstdc++} shared object needs to be available to the AIX
-runtime loader. The GCC 3.1 @samp{libstdc++.so.4} shared object can
-be installed for runtime dynamic loading using the following steps to
-set the @samp{F_LOADONLY} flag in the shared object for @emph{each}
+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 @samp{libstdc++} shared object needs to be available
+to the AIX runtime loader. The GCC 3.1 @samp{libstdc++.so.4}, if
+present, and GCC 3.3 @samp{libstdc++.so.5} shared objects can be
+installed for runtime dynamic loading using the following steps to set
+the @samp{F_LOADONLY} flag in the shared object for @emph{each}
multilib @file{libstdc++.a} installed:
-Extract the shared object from each the GCC 3.1 @file{libstdc++.a}
-archive:
+Extract the shared objects from the currently installed
+@file{libstdc++.a} archive:
@smallexample
- % ar -x libstdc++.a libstdc++.so.4
+ % ar -x libstdc++.a libstdc++.so.4 libstdc++.so.5
@end smallexample
Enable the @samp{F_LOADONLY} flag so that the shared object will be
available for runtime dynamic loading, but not linking:
@smallexample
- % strip -e libstdc++.so.4
+ % strip -e libstdc++.so.4 libstdc++.so.5
@end smallexample
-Archive the runtime-only shared object in the GCC 3.2
+Archive the runtime-only shared object in the GCC 3.4
@file{libstdc++.a} archive:
@smallexample
- % ar -q libstdc++.a libstdc++.so.4
+ % ar -q libstdc++.a libstdc++.so.4 libstdc++.so.5
@end smallexample
Linking executables and shared libraries may produce warnings of
@option{--disable-multilib}, since we will not be able to build the
64-bit target libraries.
+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.
+
@html
<hr />
@end html
projects / thirdparty / gcc.git / blobdiff