gcc.texi

GUN开源阻止下的编译器GCC

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
@file{iclib.a}.  You must also modify @file{stdio.h} as follows: before
the lines

@example
#if     defined(__i860__) && !defined(_VA_LIST)
#include <va_list.h>
@end example

@noindent
insert the line

@example
#if __PGC__
@end example

@noindent
and after the lines

@example
extern int  vprintf(const char *, va_list );
extern int  vsprintf(char *, const char *, va_list );
#endif
@end example

@noindent
insert the line

@example
#endif /* __PGC__ */
@end example

These problems don't exist in operating system version 1.1.

@item
On the Altos 3068, programs compiled with GNU CC won't work unless you
fix a kernel bug.  This happens using system versions V.2.2 1.0gT1 and
V.2.2 1.0e and perhaps later versions as well.  See the file
@file{README.ALTOS}.

@item
You will get several sorts of compilation and linking errors on the
we32k if you don't follow the special instructions.  @xref{Configurations}.

@item
A bug in the HP-UX 8.05 (and earlier) shell will cause the fixproto
program to report an error of the form:

@example
./fixproto: sh internal 1K buffer overflow
@end example

To fix this, change the first line of the fixproto script to look like:

@example
#!/bin/ksh
@end example
@end itemize

@node Cross-Compiler Problems
@section Cross-Compiler Problems

You may run into problems with cross compilation on certain machines,
for several reasons.

@itemize @bullet
@item
Cross compilation can run into trouble for certain machines because
some target machines' assemblers require floating point numbers to be
written as @emph{integer} constants in certain contexts.

The compiler writes these integer constants by examining the floating
point value as an integer and printing that integer, because this is
simple to write and independent of the details of the floating point
representation.  But this does not work if the compiler is running on
a different machine with an incompatible floating point format, or
even a different byte-ordering.

In addition, correct constant folding of floating point values
requires representing them in the target machine's format.
(The C standard does not quite require this, but in practice
it is the only way to win.)

It is now possible to overcome these problems by defining macros such
as @code{REAL_VALUE_TYPE}.  But doing so is a substantial amount of
work for each target machine.
@ifset INTERNALS
@xref{Cross-compilation}.
@end ifset
@ifclear INTERNALS
@xref{Cross-compilation,,Cross Compilation and Floating Point Format,
gcc.info, Using and Porting GCC}.
@end ifclear

@item
At present, the program @file{mips-tfile} which adds debug
support to object files on MIPS systems does not work in a cross
compile environment.
@end itemize

@node Interoperation
@section Interoperation

This section lists various difficulties encountered in using GNU C or
GNU C++ together with other compilers or with the assemblers, linkers,
libraries and debuggers on certain systems.

@itemize @bullet
@item
Objective C does not work on the RS/6000.

@item
GNU C++ does not do name mangling in the same way as other C++
compilers.  This means that object files compiled with one compiler
cannot be used with another.

This effect is intentional, to protect you from more subtle problems.
Compilers differ as to many internal details of C++ implementation,
including: how class instances are laid out, how multiple inheritance is
implemented, and how virtual function calls are handled.  If the name
encoding were made the same, your programs would link against libraries
provided from other compilers---but the programs would then crash when
run.  Incompatible libraries are then detected at link time, rather than
at run time.

@item
Older GDB versions sometimes fail to read the output of GNU CC version
2.  If you have trouble, get GDB version 4.4 or later.

@item
@cindex DBX
DBX rejects some files produced by GNU CC, though it accepts similar
constructs in output from PCC.  Until someone can supply a coherent
description of what is valid DBX input and what is not, there is
nothing I can do about these problems.  You are on your own.

@item
The GNU assembler (GAS) does not support PIC.  To generate PIC code, you
must use some other assembler, such as @file{/bin/as}.

@item
On some BSD systems, including some versions of Ultrix, use of profiling
causes static variable destructors (currently used only in C++) not to
be run.

@item
Use of @samp{-I/usr/include} may cause trouble.

Many systems come with header files that won't work with GNU CC unless
corrected by @code{fixincludes}.  The corrected header files go in a new
directory; GNU CC searches this directory before @file{/usr/include}.
If you use @samp{-I/usr/include}, this tells GNU CC to search
@file{/usr/include} earlier on, before the corrected headers.  The
result is that you get the uncorrected header files.

Instead, you should use these options (when compiling C programs):

@smallexample
-I/usr/local/lib/gcc-lib/@var{target}/@var{version}/include -I/usr/include
@end smallexample

For C++ programs, GNU CC also uses a special directory that defines C++
interfaces to standard C subroutines.  This directory is meant to be
searched @emph{before} other standard include directories, so that it
takes precedence.  If you are compiling C++ programs and specifying
include directories explicitly, use this option first, then the two
options above:

@example
-I/usr/local/lib/g++-include
@end example

@ignore
@cindex @code{vfork}, for the Sun-4
@item
There is a bug in @c