compiling gcc-1.31
Mike Haertel
mike at thor.stolaf.edu
Fri Dec 9 01:03:27 AEST 1988
As everybody on this newsgroup knows, compiling gcc on the 3b1 is a bit
of a chore, because it kind of exceeds several fixed limits of the SGS
C compiler.
Assuming you don't have a prior version of gcc to bootstrap
from (and this may not be a good idea anyway) you will run into a few
problems. First of all you will get "too much defining." You can
fix this by replacing /lib/cpp with GNU cpp (save the old cpp somewhere!)
When I last compiled gcc this way, I used cpp from the emacs 18.52
distribution (because cpp in the gcc distribution wants to include
config.h . . .) There is a large bug in the emacs 18.52 cpp; there
are a number of places where it does the comparison
if (c == (UCHAR) -1)
the cast to UCHAR needs to be removed; if I recall correctly.
Then, assuming yohave a working cpp, you will get a weird error
message from the C compiler further on; it is because of an
enum type in one of the insn-*.h files with too many members for
the poor SGS compiler to grok. You can change this file to
a bunch of #defines and that ought to solve the problem.
There may be further problems, but I don't know what they are because
I never got a chance to finish compiling gcc this way; my disk
started causing problems . . . (I don't *think* this was related
to gcc :-)
Incidentally, if it is just gnulib.c you want to compile (say,
you're bootstrapping from a prior version of gcc and you want to
compile the new gnulib with SGS cc) you can delete the line
#include "config.h" and replace it with #define WORDS_BIG_ENDIAN
because that is the only configuration parameter used in gnulib.
I am presently running gcc-1.31. I did not bootstrap from a prior
version of gcc (although in the distant past I once ran gcc-1.26).
Instead, I cross compiled gcc from another machine (a sun 3, but I
think you could probably do it from any machine). In order to do
this, one builds an almost-3b1 gcc on the sun. I slightly modified
the gcc configuration files to do this.
% diff tm-3b1.h tm-3b1-from-sun.h
63c63
< #define SDB_DEBUGGING_INFO
---
> /* #define SDB_DEBUGGING_INFO */
68c68
< #define ASM_FILE_START(FILE) sdbout_filename ((FILE), main_input_filename)
---
> #define ASM_FILE_START(FP) fprintf((FP), "\tfile\t\"%s\"\n", main_input_filename)
% diff xm-3b1.h xm-3b1-from-sun.h
1,2d0
< #define USG
<
The main thing is you have to turn off SDB_DEBUGGING_INFO, and then you
have to slightly fix ASM_FILE_START because you turned it off.
The next thing is to copy the unix-pc include hierarchy over to the
Sun. Now one reconfigures gcc with the default 3b1 configuration, and
uses the almost-3b1 gcc just made to compile each c source file to
an assembly language .s file, for example:
% gcc -B./ -I3b1include -S -O toplev.c
One then copies the .s files and gnulib.c to the 3b1, fixes gnulib.c so
it compiles without config.h and builds gnulib, assembles the .s files,
and load gcc, cc1, and cccp from the appropirate .o files with gnulib.
(I used the shared library as well, and it worked.)
I haven't gotten around to testing the thing much, but -O and -g both
seem to work; I have successfully compiled the (as yet unreleased)
GNU sort program that I wrote. I am going to copy the whole gcc
distribution over; if gcc running on the 3b1 generates exactly the
same .s files as gcc running on the Sun did (I have no reason to expect
that it won't) then I will consider it to have passed that test. I
will also use it to compile Emacs, TeX, and Metafont. With the
latter two there are extensive test suites that I will run the results
through; since TeX compiled with gcc-1.26 passed the trip test, I
expect that TeX compiled with 1.31 will as well . . .
Finally, no promises, but I may be able to make some 3b1 gcc binaries
available via anonymous ftp from prep.
--
Mike Haertel mike at wheaties.ai.mit.edu
In Hell they run VMS.
More information about the Unix-pc.general
mailing list