Using and Porting GNU CC - Installation Problems

Go to the previous, next 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.

On certain systems, defining certain environment variables such as CC can interfere with the functioning of make.
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. See section Compilation in a Separate Directory.
If you build GNU CC on a BSD system using a directory stored in a System V file system, problems may occur in running fixincludes if the System V file system doesn't support symbolic links. These problems result in a failure to fix the declaration of size_t in `sys/types.h'. If you find that 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.
In previous versions of GNU CC, the gcc driver program looked for as and ld in various places; for example, in files beginning with `/usr/local/lib/gcc-'. GNU CC version 2 looks for them in the directory `/usr/local/lib/gcc-lib/target/version'.
Thus, to use a version of as or 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).
Some commands executed when making the compiler may fail (return a non-zero status) and be ignored by make. These failures, which are often due to files that were not found, are expected, and can safely be ignored.
It is normal to have warnings in compiling certain files about unreachable code and about enumeration type clashes. These files' names begin with `insn-'. Also, `real.c' may get some warnings that you can ignore.
Sometimes make recompiles 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.
If you have installed a program known as purify, you may find that it causes errors while linking enquire, which is part of building GNU CC. The fix is to get rid of the file real-ld which purify installs--so that GNU CC won't try to use it.
On Linux SLS 1.01, there is a problem with `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 `#if 1'.
On some 386 systems, building the compiler never finishes because 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 `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'.
On some 386 systems, GNU CC crashes trying to compile `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 `emulator.dflt'.)
Try using `/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:
```
enquire.c: In function `fprop':
enquire.c:2328: floating overflow
```
On SCO systems, when compiling GNU CC with the system's compiler, do not use `-O'. Some versions of the system's compiler miscompile GNU CC with `-O'.
Sometimes on a Sun 4 you may observe a crash in the program genflags or genoutput while building GNU CC. This is said to be due to a bug in sh. You can probably get around it by running genflags or genoutput manually and then retrying the make.
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 `-g'.
The solution is to compile the current version of GNU CC without `-g'. That makes a working compiler which you can use to recompile with `-g'.
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 pkginfo command. To add an optional package, use the pkgadd command. For further details, see the Solaris documentation.
For Solaris 2.0 and 2.1, GNU CC needs six packages: `SUNWarc', `SUNWbtool', `SUNWesu', `SUNWhea', `SUNWlibm', and `SUNWtoo'.
For Solaris 2.2, GNU CC needs an additional seventh package: `SUNWsprot'.
On Solaris 2, trying to use the linker and other tools in `/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 PATH.
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 add.d.
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.
In Ultrix 4.0 on the MIPS machine, `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:
```
CFLAGS="-g -I./include"
```
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.
Some versions of the MIPS linker will issue an assertion failure when linking code that uses 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 `-non_shared' to the linker unless you pass an explicit `-shared' or `-call_shared' switch.
On System V release 3, you may get this error message while linking:
```
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 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.

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

/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 MAXUMEM.

Current GNU CC versions probably do not work on version 2 of the NeXT operating system.
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.
On the Tower models 4n0 and 6n0, 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 `-O' in that much memory.
To solve this problem, reconfigure the kernel adding the following line to the configuration file:
```
MAXUMEM = 4096
```
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 `libgcc2.a':
```
_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 following note:

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.
On HP-UX version 8.05, but not on 8.07 or more recent versions, the 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 fixproto.
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 muldi3 in 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.
There may be similar problems on System V Release 3.1 on 386 systems.
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 va_arg when 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 the lines
```
#if     defined(__i860__) && !defined(_VA_LIST)
#include <va_list.h>
```
insert the line
```
#if __PGC__
```
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.
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 `README.ALTOS'.
You will get several sorts of compilation and linking errors on the we32k if you don't follow the special instructions. See section Installing GNU CC on the WE32K.

Go to the previous, next section.