Using and Porting GNU CC
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.
CCcan interfere with the functioning of
fixincludesif the System V file system doesn't support symbolic links. These problems result in a failure to fix the declaration of
sys/types.h'. If you find that
size_tis 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.
gccdriver program looked for
ldin various places; for example, in files beginning with `
/usr/local/lib/gcc-'. GNU CC version 2 looks for them in the directory `
Thus, to use a version of
ld that is not the system
default, for example
gas or GNU
ld, you must put them in
that directory (or make links to them from that directory).
make. These failures, which are often due to files that were not found, are expected, and can safely be ignored.
insn-'. Also, `
real.c' may get some warnings that you can ignore.
makerecompiles parts of the compiler when installing the compiler. In one case, this was traced down to a bug in
make. Either ignore the problem or switch to GNU Make.
enquire, which is part of building GNU CC. The fix is to get rid of the file
real-ldwhich purify installs---so that GNU CC won't try to use it.
libc.a': it does not contain the obstack functions. However, GNU CC assumes that the obstack functions are in `
libc.a' when it is the GNU C library. To work around this problem, change the
__GNU_LIBRARY__conditional around line 31 to `
enquirehangs due to a hardware problem in the motherboard---it reports floating point exceptions to the kernel incorrectly. You can install GNU CC except for `
float.h' by patching out the command to run
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 `
hd(40)unix auto ignorefpu'.
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:
ln /etc/emulator.rel1 /etc/emulator
and then reboot the system. (The default emulator file remains present
under the name `
Try using `
/etc/emulator.att', if you have such a problem on the
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:
enquire.c: In function `fprop': enquire.c:2328: floating overflow
-O'. Some versions of the system's compiler miscompile GNU CC with `
genoutputwhile building GNU CC. This is said to be due to a bug in
sh. You can probably get around it by running
genoutputmanually and then retrying the
The solution is to compile the current version of GNU CC without
-g'. That makes a working compiler which you can use to recompile
To check whether an optional package is installed, use
pkginfo command. To add an optional package, use the
pkgadd command. For further details, see the Solaris
For Solaris 2.0 and 2.1, GNU CC needs six packages: `
For Solaris 2.2, GNU CC needs an additional seventh package: `
/usr/ucb' to install GNU CC has been observed to cause trouble. For example, the linker may hang indefinitely. The fix is to remove `
/usr/ucb' from your
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.
stdio.h' does not work with GNU CC at all unless it has been fixed with
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:
GCC_FOR_TARGET="./xgcc -B./ -I./include"
When making stage 2 and stage 3, specify this option:
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.
allocaagainst 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 `
-non_shared' to the linker unless you pass an explicit `
-shared' or `
ld fatal: failed to write symbol name something in strings table for file whatever
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
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.
/usr/local/lib/bison.simple: In function `yyparse': /usr/local/lib/bison.simple:625: virtual memory exhausted
that too indicates a problem with disk space, ULIMIT, or
-O' in that much memory.
To solve this problem, reconfigure the kernel adding the following line to the configuration file:
MAXUMEM = 4096
_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
A patched version of the assembler is available by anonymous ftp from
altdorf.ai.mit.edu as the 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
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.
This patch is also known as PHCO_0800.
fixprotoshell 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
muldi3in file `
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.
va_argwhen you build GNU CC.
If this happens, then you need to link most programs with the library
iclib.a'. You must also modify `
stdio.h' as follows: before
#if defined(__i860__) && !defined(_VA_LIST) #include <va_list.h>
insert the line
and after the lines
extern int vprintf(const char *, va_list ); extern int vsprintf(char *, const char *, va_list ); #endif
insert the line
#endif /* __PGC__ */
These problems don't exist in operating system version 1.1.
./fixproto: sh internal 1K buffer overflow
To fix this, change the first line of the fixproto script to look like: