The `fixincludes' installation step described here applies only to the native configuration of the Developer's Kit---that is, only if your tape is configured to develop software for the same host on which it runs. If you have a cross-development tape, configured to develop software for another machine (the target), the system header files from your host are not needed for the GNU compilers. Cross-development tapes have `target = target' on the tape label.
For the native configuration, it is very important to run `Install fixincludes' (on each host where you install the compiler binaries).
When the ANSI X3J11 committee finished developing a standard for the C language, a few things that had worked one way in many traditional C compilers ended up working differently in ANSI C. Most of these changes are improvements. But some Unix header files still rely on the old C meanings, in cases where the Unix vendor has not yet converted to using an ANSI C compiler for the operating system itself. `Install fixincludes' does a mechanical translation that writes ANSI C versions of some system header files into a new, GCC-specific include directory---your system's original header files are not affected.
The C header files supplied with SVr4 versions of Unix depend on a
questionable interpretation of the ANSI C standard: they test for a
non-ANSI environment by checking whether __STDC__ is
defined as zero. The ANSI standard actually only specifies that
__STDC__ be defined to 1; if it is defined to any other value,
the environment is not ANSI C compatible, and ANSI C says
nothing about what that value might be.
GCC defines __STDC__ to 1 when running with `-ansi',
when it functions as an "ANSI C superset" compiler. (It also
sets __STRICT_ANSI__ when it runs with the `-pedantic'
option.) However, GCC leaves __STDC__ undefined when it is
not running as an ANSI C compiler.
Unfortunately for Solaris users, Solaris header files follow the SVr4
choice. Since GCC never defines __STDC__ as 0, the
distributed header files can leave out some declarations. (Look in
`/usr/include/time.h', for example.)
Part of the installation process of the native compiler release is to "fix" the header files, such as `stdio.h', on the host system to remove ANSI incompatibilities. `Install fixincludes' makes copies of the system `include' files which have these nonstandard features removed, so that GCC can process them. These copies are placed in a new, GCC-specific `include' directory---your system's original header files are not affected. Once these fixed header files are created, GCC finds and uses them automatically.
Likewise, C++ programmers require C++-ready, ANSI-compatible
versions of the standard C header files. These used to be provided with
libg++, but were difficult to maintain due to the design
compromises (and outright "kludges") that were necessary to make these
work on all the systems we support.
We have recently introduced what we believe to be a better solution in
the form of a new shell script, fixproto. fixproto
analyzes all the header files in `/usr/include', and adds any
missing standard ANSI and Posix.2 prototypes. The `extern
"C"' braces needed to specify that these are C (not C++) functions are
also added as needed. It is run as part of the installation and/or
build of a native compiler. The resulting header files are also used
for C, with the result that the `-Wimplicit' option for gcc
is much more useful.
The most obvious drawback to this solution is that the process of "fixing" the `include' files takes longer to run, so any installation of a native compiler is noticeably slower than in previous releases. Performance improvements will be made as part of a future release.
If you don't run fixincludes, the GNU C compiler can only
use the original system header files when you compile new C programs.
In some cases, the resulting programs will fail at run-time.