gcc.texi

来自「GCC编译器源代码」· TEXI 代码 · 共 1,739 行 · 第 1/5 页

The @code{fixincludes} script interacts badly with automounters; if the
directory of system header files is automounted, it tends to be
unmounted while @code{fixincludes} is running.  This would seem to be a
bug in the automounter.  We don't know any good way to work around it.

@item
The @code{fixproto} script will sometimes add prototypes for the
@code{sigsetjmp} and @code{siglongjmp} functions that reference the
@code{jmp_buf} type before that type is defined.  To work around this,
edit the offending file and place the typedef in front of the
prototypes.

@item
There are several obscure case of mis-using struct, union, and
enum tags that are not detected as errors by the compiler.

@item
When @samp{-pedantic-errors} is specified, GNU C will incorrectly give
an error message when a function name is specified in an expression
involving the comma operator.

@item
Loop unrolling doesn't work properly for certain C++ programs.  This is
a bug in the C++ front end.  It sometimes emits incorrect debug info, and
the loop unrolling code is unable to recover from this error.
@end itemize

@node Installation Problems
@section Installation Problems

This is a list of problems (and some apparent problems which don't
really mean anything is wrong) that show up during installation of GNU
CC.

@itemize @bullet
@item
On certain systems, defining certain environment variables such as
@code{CC} can interfere with the functioning of @code{make}.

@item
If you encounter seemingly strange errors when trying to build the
compiler in a directory other than the source directory, it could be
because you have previously configured the compiler in the source
directory.  Make sure you have done all the necessary preparations.
@xref{Other Dir}.

@item
If you build GNU CC on a BSD system using a directory stored in a System
V file system, problems may occur in running @code{fixincludes} if the
System V file system doesn't support symbolic links.  These problems
result in a failure to fix the declaration of @code{size_t} in
@file{sys/types.h}.  If you find that @code{size_t} is a signed type and
that type mismatches occur, this could be the cause.

The solution is not to use such a directory for building GNU CC.

@item
In previous versions of GNU CC, the @code{gcc} driver program looked for
@code{as} and @code{ld} in various places; for example, in files
beginning with @file{/usr/local/lib/gcc-}.  GNU CC version 2 looks for
them in the directory
@file{/usr/local/lib/gcc-lib/@var{target}/@var{version}}.

Thus, to use a version of @code{as} or @code{ld} that is not the system
default, for example @code{gas} or GNU @code{ld}, you must put them in
that directory (or make links to them from that directory).

@item
Some commands executed when making the compiler may fail (return a
non-zero status) and be ignored by @code{make}.  These failures, which
are often due to files that were not found, are expected, and can safely
be ignored.

@item
It is normal to have warnings in compiling certain files about
unreachable code and about enumeration type clashes.  These files' names
begin with @samp{insn-}.  Also, @file{real.c} may get some warnings that
you can ignore.

@item
Sometimes @code{make} recompiles parts of the compiler when installing
the compiler.  In one case, this was traced down to a bug in
@code{make}.  Either ignore the problem or switch to GNU Make.

@item
If you have installed a program known as purify, you may find that it
causes errors while linking @code{enquire}, which is part of building
GNU CC.  The fix is to get rid of the file @code{real-ld} which purify
installs---so that GNU CC won't try to use it.

@item
On GNU/Linux SLS 1.01, there is a problem with @file{libc.a}: it does not
contain the obstack functions.  However, GNU CC assumes that the obstack
functions are in @file{libc.a} when it is the GNU C library.  To work
around this problem, change the @code{__GNU_LIBRARY__} conditional
around line 31 to @samp{#if 1}.

@item
On some 386 systems, building the compiler never finishes because
@code{enquire} hangs due to a hardware problem in the motherboard---it
reports floating point exceptions to the kernel incorrectly.  You can
install GNU CC except for @file{float.h} by patching out the command to
run @code{enquire}.  You may also be able to fix the problem for real by
getting a replacement motherboard.  This problem was observed in
Revision E of the Micronics motherboard, and is fixed in Revision F.
It has also been observed in the MYLEX MXA-33 motherboard.

If you encounter this problem, you may also want to consider removing
the FPU from the socket during the compilation.  Alternatively, if you
are running SCO Unix, you can reboot and force the FPU to be ignored.
To do this, type @samp{hd(40)unix auto ignorefpu}.

@item
On some 386 systems, GNU CC crashes trying to compile @file{enquire.c}.
This happens on machines that don't have a 387 FPU chip.  On 386
machines, the system kernel is supposed to emulate the 387 when you
don't have one.  The crash is due to a bug in the emulator.

One of these systems is the Unix from Interactive Systems: 386/ix.
On this system, an alternate emulator is provided, and it does work.
To use it, execute this command as super-user:

@example
ln /etc/emulator.rel1 /etc/emulator
@end example

@noindent
and then reboot the system.  (The default emulator file remains present
under the name @file{emulator.dflt}.)

Try using @file{/etc/emulator.att}, if you have such a problem on the
SCO system.

Another system which has this problem is Esix.  We don't know whether it
has an alternate emulator that works.

On NetBSD 0.8, a similar problem manifests itself as these error messages:

@example
enquire.c: In function `fprop':
enquire.c:2328: floating overflow
@end example

@item
On SCO systems, when compiling GNU CC with the system's compiler,
do not use @samp{-O}.  Some versions of the system's compiler miscompile
GNU CC with @samp{-O}.

@cindex @code{genflags}, crash on Sun 4
@item
Sometimes on a Sun 4 you may observe a crash in the program
@code{genflags} or @code{genoutput} while building GNU CC.  This is said to
be due to a bug in @code{sh}.  You can probably get around it by running
@code{genflags} or @code{genoutput} manually and then retrying the
@code{make}.

@item
On Solaris 2, executables of GNU CC version 2.0.2 are commonly
available, but they have a bug that shows up when compiling current
versions of GNU CC: undefined symbol errors occur during assembly if you
use @samp{-g}.

The solution is to compile the current version of GNU CC without
@samp{-g}.  That makes a working compiler which you can use to recompile
with @samp{-g}.

@item
Solaris 2 comes with a number of optional OS packages.  Some of these
packages are needed to use GNU CC fully.  If you did not install all
optional packages when installing Solaris, you will need to verify that
the packages that GNU CC needs are installed.

To check whether an optional package is installed, use
the @code{pkginfo} command.  To add an optional package, use the
@code{pkgadd} command.  For further details, see the Solaris
documentation.

For Solaris 2.0 and 2.1, GNU CC needs six packages: @samp{SUNWarc},
@samp{SUNWbtool}, @samp{SUNWesu}, @samp{SUNWhea}, @samp{SUNWlibm}, and
@samp{SUNWtoo}.

For Solaris 2.2, GNU CC needs an additional seventh package: @samp{SUNWsprot}.

@item
On Solaris 2, trying to use the linker and other tools in
@file{/usr/ucb} to install GNU CC has been observed to cause trouble.
For example, the linker may hang indefinitely.  The fix is to remove
@file{/usr/ucb} from your @code{PATH}.

@item
If you use the 1.31 version of the MIPS assembler (such as was shipped
with Ultrix 3.1), you will need to use the -fno-delayed-branch switch
when optimizing floating point code.  Otherwise, the assembler will
complain when the GCC compiler fills a branch delay slot with a
floating point instruction, such as @code{add.d}.

@item
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.

@item
In Ultrix 4.0 on the MIPS machine, @file{stdio.h} does not work with GNU
CC at all unless it has been fixed with @code{fixincludes}.  This causes
problems in building GNU CC.  Once GNU CC is installed, the problems go
away.

To work around this problem, when making the stage 1 compiler, specify
this option to Make:

@example
GCC_FOR_TARGET="./xgcc -B./ -I./include"
@end example

When making stage 2 and stage 3, specify this option:

@example
CFLAGS="-g -I./include"
@end example

@item
Users have reported some problems with version 2.0 of the MIPS
compiler tools that were shipped with Ultrix 4.1.  Version 2.10
which came with Ultrix 4.2 seems to work fine.

Users have also reported some problems with version 2.20 of the
MIPS compiler tools that were shipped with RISC/os 4.x.  The earlier
version 2.11 seems to work fine.

@item
Some versions of the MIPS linker will issue an assertion failure
when linking code that uses @code{alloca} against shared
libraries on RISC-OS 5.0, and DEC's OSF/1 systems.  This is a bug
in the linker, that is supposed to be fixed in future revisions.
To protect against this, GNU CC passes @samp{-non_shared} to the
linker unless you pass an explicit @samp{-shared} or
@samp{-call_shared} switch.

@item
On System V release 3, you may get this error message
while linking:

@smallexample
ld fatal: failed to write symbol name @var{something}
 in strings table for file @var{whatever}
@end smallexample

This probably indicates that the disk is full or your ULIMIT won't allow
the file to be as large as it needs to be.

This problem can also result because the kernel parameter @code{MAXUMEM}
is too small.  If so, you must regenerate the kernel and make the value
much larger.  The default value is reported to be 1024; a value of 32768
is said to work.  Smaller values may also work.

@item
On System V, if you get an error like this,

@example
/usr/local/lib/bison.simple: In function `yyparse':
/usr/local/lib/bison.simple:625: virtual memory exhausted
@end example

@noindent
that too indicates a problem with disk space, ULIMIT, or @code{MAXUMEM}.

@item
Current GNU CC versions probably do not work on version 2 of the NeXT
operating system.

@item
On NeXTStep 3.0, the Objective C compiler does not work, due,
apparently, to a kernel bug that it happens to trigger.  This problem
does not happen on 3.1.

@item
On the Tower models 4@var{n}0 and 6@var{n}0, by default a process is not
allowed to have more than one megabyte of memory.  GNU CC cannot compile
itself (or many other programs) with @samp{-O} in that much memory.

To solve this problem, reconfigure the kernel adding the following line
to the configuration file:

@smallexample
MAXUMEM = 4096
@end smallexample

@item
On HP 9000 series 300 or 400 running HP-UX release 8.0, there is a bug
in the assembler that must be fixed before GNU CC can be built.  This
bug manifests itself during the first stage of compilation, while
building @file{libgcc2.a}:

@smallexample
_floatdisf
cc1: warning: `-g' option not supported on this version of GCC
cc1: warning: `-g1' option not supported on this version of GCC
./xgcc: Internal compiler error: program as got fatal signal 11
@end smallexample

A patched version of the assembler is available by anonymous ftp from
@code{altdorf.ai.mit.edu} as the file
@file{archive/cph/hpux-8.0-assembler}.  If you have HP software support,
the patch can also be obtained directly from HP, as described in the
following note:

@quotation
This is the patched assembler, to patch SR#1653-010439, where the
assembler aborts on floating point constants.

The bug is not really in the assembler, but in the shared library
version of the function ``cvtnum(3c)''.  The bug on ``cvtnum(3c)'' is
SR#4701-078451.  Anyway, the attached assembler uses the archive
library version of ``cvtnum(3c)'' and thus does not exhibit the bug.
@end quotation

This patch is also known as PHCO_4484.

@item
On HP-UX version 8.05, but not on 8.07 or more recent versions,
the @code{fixproto} shell script triggers a bug in the system shell.
If you encounter this problem, upgrade your operating system or
use BASH (the GNU shell) to run @code{fixproto}.

@item
Some versions of the Pyramid C compiler are reported to be unable to
compile GNU CC.  You must use an older version of GNU CC for
bootstrapping.  One indication of this problem is if you get a crash
when GNU CC compiles the function @code{muldi3} in file @file{libgcc2.c}.

You may be able to succeed by getting GNU CC version 1, installing it,
and using it to compile GNU CC version 2.  The bug in the Pyramid C
compiler does not seem to affect GNU CC version 1.

@item
There may be similar problems on System V Release 3.1 on 386 systems.

@item
On the Intel Paragon (an i860 machine), if you are using operating
system version 1.0, you will get warnings or errors about redefinition
of @code{va_arg} when you build GNU CC.

If this happens, then you need to link most programs with the library