Path: utzoo!utgpu!watmath!uunet!xanth!nic.MR.NET!thor!mike From: mike@thor.stolaf.edu (Mike Haertel) Newsgroups: unix-pc.general Subject: compiling gcc-1.31 Message-ID: <796@thor.stolaf.edu> Date: 8 Dec 88 15:03:27 GMT Reply-To: mike@wheaties.ai.mit.edu Organization: St. Olaf College, Northfield, MN. Lines: 82 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@wheaties.ai.mit.edu In Hell they run VMS.