GNU Info
(gcc-295.info)Installation Problems
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. Note: Other Dir.
* If you build GCC 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 GCC.
* In previous versions of GCC, the `gcc' driver program looked for
`as' and `ld' in various places; for example, in files beginning
with `/usr/local/lib/gcc-'. GCC 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
GCC. The fix is to get rid of the file `real-ld' which purify
installs--so that GCC won't try to use it.
* On GNU/Linux SLS 1.01, there is a problem with `libc.a': it does
not contain the obstack functions. However, GCC 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 GCC 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, GCC 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 GCC with the system's compiler, do
not use `-O'. Some versions of the system's compiler miscompile
GCC with `-O'.
* Sometimes on a Sun 4 you may observe a crash in the program
`genflags' or `genoutput' while building GCC. 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 GCC version 2.0.2 are commonly
available, but they have a bug that shows up when compiling current
versions of GCC: undefined symbol errors occur during assembly if
you use `-g'.
The solution is to compile the current version of GCC 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 GCC fully. If you did not
install all optional packages when installing Solaris, you will
need to verify that the packages that GCC 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, GCC needs six packages: `SUNWarc',
`SUNWbtool', `SUNWesu', `SUNWhea', `SUNWlibm', and `SUNWtoo'.
For Solaris 2.2, GCC needs an additional seventh package:
`SUNWsprot'.
* On Solaris 2, trying to use the linker and other tools in
`/usr/ucb' to install GCC 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 GCC. Once GCC 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.
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.
* 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, GCC 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 GCC 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. GCC 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 GCC 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_4484.
* 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 GCC. You must use an older version of GCC for
bootstrapping. One indication of this problem is if you get a
crash when GCC compiles the function `muldi3' in file `libgcc2.c'.
You may be able to succeed by getting GCC version 1, installing it,
and using it to compile GCC version 2. The bug in the Pyramid C
compiler does not seem to affect GCC 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 GCC.
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 GCC 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. Note:
Configurations.
* A bug in the HP-UX 8.05 (and earlier) shell will cause the fixproto
program to report an error of the form:
./fixproto: sh internal 1K buffer overflow
To fix this, change the first line of the fixproto script to look
like:
#!/bin/ksh
automatically generated by info2www version 1.2.2.9