herndon@milo.SRC.Honeywell.COM (William Herndon) (06/06/89)
First, of all thanks to all those who sent me patches that would
allow gcc to compile on my 3b1.
Now, on to the current problem. I have managed to get gcc, version
1.35, to compile using cc. The executable of the parser is about
6.6M and appears to run correctly. After completing the initial
make, I tried to recompile gcc with itself, as the installation guide
suggested. The compile proceeds smoothly until the cc1 starts work
on c-parse.tab.c. After thinking about it for a few minutes unix
complains about virtual memory being exhausted, and the make aborts.
Below is all the relevant information I can think of:
- My system is a 3b1 with 2M of onboard memory. ( 40M drive ).
- I do not have Bison running so a new c-parse.tab.c has not been
created.
- The compilation always aborts in the same place.
- I have attempted to create more space ( swap I assume ) by
running as root with no window manager. I have even gone
so far as to kill off the phone manager and lp scheduler to
free up more space.
- The initial compilation with cc was using -O. So gcc, cc1, and
cpp are optimized.
- I have the same problem attempting to compile GNU Emacs file
regexp.c.
Any body have ideas? Encountered the same problem? Any and all
help is appreciated.
---------------------------------------------------------------------------
William R. Herndon WHerndon@cim-vax.honeywell.com
herndon@src.honeywell.com
SCTC, Honeywell
2855 Anthony Ln. So. #130 (612) 782-7108
St. Anthony, Mn. 55418
The opinions expressed are solely those of the author. Any resemblance
to other opinions, either living or dead, is purely coincidental.alex@wolf.umbc.edu (Alex Crain) (06/07/89)
In article <23146@srcsip.UUCP>, herndon@milo.SRC.Honeywell.COM (William Herndon) writes: > suggested. The compile proceeds smoothly until the cc1 starts work > on c-parse.tab.c. After thinking about it for a few minutes unix > complains about virtual memory being exhausted, and the make aborts. Try compiling without -O (this works with 1.31) This is becoming a serious problem (the size of gcc). Virtual memory exausted means that you have run out of virtual address space, a problem wothout a solution. The worst case that I've seen is in gas. the file m68k.c in gas kills gcc with virtual memory exausted, and also causes cc to produce bogus assembly code! The solution that time was to split the file into two smaller files and link the objects together (yuuch!) but that won't work with large bison output because bison output is generally one function (double yuck!) that can't be split. It would be nice if gcc got more effecient, but since the usually culprit is bison/yacc files, one option is to do an end run around the problem and build a bison that would buoid a jump table of absolute branches, and then compile the individual cases separately as static functions using common global variables. Kinda gross, but it'll hold us over until somebody profiles the memory allocation in gcc. ################################# :alex. #Disclamer: Anyone who agrees # University of Maryland Baltimore County #with me deserves what they get.# alex@umbc3.umbc.edu ################################# alex%nerwin@umbc3.umbc.edu
kevin@kosman.UUCP (Kevin O'Gorman) (06/07/89)
In article <23146@srcsip.UUCP> herndon@milo.SRC.Honeywell.COM (William Herndon) writes: > Now, on to the current problem. I have managed to get gcc, version > 1.35, to compile using cc. The executable of the parser is about > 6.6M and appears to run correctly. After completing the initial > make, I tried to recompile gcc with itself, as the installation guide > suggested. The compile proceeds smoothly until the cc1 starts work > on c-parse.tab.c. After thinking about it for a few minutes unix > complains about virtual memory being exhausted, and the make aborts. > Any body have ideas? Encountered the same problem? Any and all > help is appreciated. No particular ideas, at least about why this happens to you. Well, one idea: cc may be so busted that the resulting gcc is also busted. I have gcc 1.35 running on my 3b1 (with 2.5 MB main memory, and a swap space of 5000 blocks). It was compiled by bootstrapping from a previous version, without any reported memory trouble. I run with UA, as a normal user, all the time. The port from cc to gcc was done many versions ago by someone else. You might want to run iv -tv /dev/rfp000 # type this exactly. Do not goof. to see the size of your swap space (the second partition, "Part 1").