have @file{/usr/xpg4/bin} in your @env{PATH}, we recommend that you place
@file{/usr/bin} before @file{/usr/xpg4/bin} for the duration of the build.
-All releases of GNU binutils prior to 2.11.2 have known bugs on this
-platform. We recommend the use of GNU binutils 2.11.2 or later, or the
-vendor tools (Sun @command{as}, Sun @command{ld}). Note that your mileage
-may vary if you use a combination of the GNU tools and the Sun tools: while
-the combination GNU @command{as} + Sun @command{ld} should reasonably work,
+We recommend the use of GNU binutils 2.14 or later, or the vendor tools
+(Sun @command{as}, Sun @command{ld}). Note that your mileage may vary
+if you use a combination of the GNU tools and the Sun tools: while the
+combination GNU @command{as} + Sun @command{ld} should reasonably work,
the reverse combination Sun @command{as} + GNU @command{ld} is known to
cause memory corruption at runtime in some cases for C++ programs.
@uref{http://sourceware.org/ml/binutils-cvs/2004-09/msg00036.html} to the
release.
-We recommend using GNU binutils 2.16 or later in conjunction with GCC 4.x,
-or the vendor tools (Sun @command{as}, Sun @command{ld}). However, for
-Solaris 10 and above, an additional patch is required in order for the GNU
-linker to be able to cope with a new flavor of shared libraries. You
+We recommend the use of GNU binutils 2.16 or later in conjunction with GCC
+4.x, or the vendor tools (Sun @command{as}, Sun @command{ld}). However,
+for Solaris 10 and above, an additional patch is required in order for the
+GNU linker to be able to cope with a new flavor of shared libraries. You
can obtain a working version by checking out the binutils-2_16-branch from
the CVS repository or applying the patch
@uref{http://sourceware.org/ml/binutils-cvs/2005-07/msg00122.html} to the
release.
Sun bug 4296832 turns up when compiling X11 headers with GCC 2.95 or
-newer: @command{g++} will complain that types are missing. These headers assume
-that omitting the type means @code{int}; this assumption worked for C89 but
-is wrong for C++, and is now wrong for C99 also.
+newer: @command{g++} will complain that types are missing. These headers
+assume that omitting the type means @code{int}; this assumption worked for
+C89 but is wrong for C++, and is now wrong for C99 also.
@command{g++} accepts such (invalid) constructs with the option
-@option{-fpermissive}; it
-will assume that any missing type is @code{int} (as defined by C89).
+@option{-fpermissive}; it will assume that any missing type is @code{int}
+(as defined by C89).
-There are patches for Solaris 2.6 (105633-56 or newer for SPARC,
-106248-42 or newer for Intel), Solaris 7 (108376-21 or newer for SPARC,
+There are patches for Solaris 7 (108376-21 or newer for SPARC,
108377-20 for Intel), and Solaris 8 (108652-24 or newer for SPARC,
108653-22 for Intel) that fix this bug.
@end html
@heading @anchor{sparc-sun-solaris2}sparc-sun-solaris2*
-When GCC is configured to use binutils 2.11.2 or later the binaries
+When GCC is configured to use 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.
-Sun @command{as} 4.x is broken in that it cannot cope with long symbol names.
-A typical error message might look similar to the following:
-
-@smallexample
-/usr/ccs/bin/as: "/var/tmp/ccMsw135.s", line 11041: error:
- can't compute value of an expression involving an external symbol.
-@end smallexample
-
-This is Sun bug 4237974. This is fixed with patch 108908-02 for Solaris
-2.6 and has been fixed in later (5.x) versions of the assembler,
-starting with Solaris 7.
-
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 @option{-m64} option enables 64-bit code generation.
projects / gcc.git / commitdiff