Contents|Index|Previous|Next
Installation
problems
The following describes
a list of problems (and some apparent problems which dont 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 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 doesnt 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. The names of these files 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
installsso that GNU CC wont 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 motherboardit 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 dont have a 387 FPU chip. On 386 machines,
the system kernel is supposed to emulate the 387 when you dont 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 the following command
as super-user and then reboot the system.
ln /etc/emulator.rel1 /etc/emulator
(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 dont know whether it has an alternate emulator that
works.
On NetBSD 0.8, a similar problem
manifests itself as the following error messages:
enquire.c: In function 'fprop':
enquire.c:2328: floating overflow
On SCO systems, when compiling
GNU CC with the systems compiler, do not use -O.
Some versions of the systems 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 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 its
[sic]
sectons [sic],
dont 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 the following 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 DECs 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 the following 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 wont 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, 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 the following example shows, this indicates a problem with disk space,
ULIMIT, or MAXUMEM.
/usr/local/lib/bison.simple: In function 'yyparse':
/usr/local/lib/bison.simple:625: virtual memory exhausted
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 HPUX release 8.0, there is a bug in the assembler that must be
fixed before GNU CC can be built. This bug manifests during the first stage
of compilation, while building libgcc2.a.
_floatdisf
cc1: warning: -g option not supported on this of GCC
cc1: warning: -g1 option not supported on this version of GCC
./xgcc: Internal compiler error: program as got fatal signal 11
archive/cph/hpux-8.0-assembler,
a patched version of the assembler, is available by anonymous ftp from
altdorf.ai.mit.edu.
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 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 following lines, insert the line, #if
__PGC__,
#if defined(__i860__) && !defined(_VA_LIST)
#include <va_list.h>
After the following lines, insert
the line, #endif /*
__PGC__ */.
extern int vprintf(const char *, va_list );
extern int vsprintf(char *, const char *, va_list );
#endif
These problems dont exist in
operating system version 1.1.
On the Altos 3068, programs
compiled with GNU CC wont 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 dont follow the special
instructions. See Configurations
supported by GNU CC.
A bug in the HPUX 8.05 (and
earlier) shell will cause the fixproto
program to report an error of the following form.
./fixproto: sh internal 1K buffer overflow
To fix this, change the first
line of the fixproto
script to look like the following.
#!/bin/ksh
Top|Contents|Index|Previous|Next