mcm@peach.ucsb.edu (Marcelo C. Mourier) (03/13/90)
Hi there!
I'm having some trouble completing the 1.5.0 upgrade. I have success-
fully upgraded the include, library, commands, and mm; however, I couldn't
complete the upgrading of the kernel and the fs. Maybe someone who has run
into the same problem could give me a clue of how to solve it. This is
what's happening:
When make is processing kernel/system.c cpp complains with the following me-
ssage:
"system.c", line 89: fatal error -- cannot find include file "protect.h"
"./proc.h", line 28: } missing
"./proc.h", line 28: ; missing
However, file protect.h is indeed present and it has the correct crc. The
same thing happens while make is processing fs/misc.c, cpp complains with:
"misc.c", line 26: fatal error -- cannot find include file "super.h"
"./file.h", line 6: type_identifier missing
"./file.h", line 6: identifier missing
"./file.h", line 6: (warning) no semicolon after declarator
"./file.h", line 6: } missing
"./file.h", line 6: ; missing
Again, file super.h does exist and has the correct crc. There were no such
problems while making mm; I don't have any idea of what could possibly be
happening... Any suggestions..?
Thanks a lot for your time and help.
Marcelo - mcm@cs.ucsb.eduabrams@cs.columbia.edu (Steven Abrams) (03/13/90)
In article <4296@hub.UUCP> mcm@peach.ucsb.edu (Marcelo C. Mourier) writes: > When make is processing kernel/system.c cpp complains with the following me- > ssage: > > "system.c", line 89: fatal error -- cannot find include file "protect.h" > "./proc.h", line 28: } missing > "./proc.h", line 28: ; missing > > However, file protect.h is indeed present and it has the correct crc. The > same thing happens while make is processing fs/misc.c, cpp complains with: > > "misc.c", line 26: fatal error -- cannot find include file "super.h" > "./file.h", line 6: type_identifier missing > "./file.h", line 6: identifier missing > "./file.h", line 6: (warning) no semicolon after declarator > "./file.h", line 6: } missing > "./file.h", line 6: ; missing > > Again, file super.h does exist and has the correct crc. There were no such > problems while making mm; I don't have any idea of what could possibly be > happening... Any suggestions..? > Yes, this plagued me during one of my earlier upgrade attempts. You need to chmem all passes of the compiler way up to handle much of the new code, especially cpp. I just hit them all with: chmem /bin/cxxx +=60000 and this solved the problem. The compiler really ought to know that it ran out of memory and not that there's something wrong with your files. Oh well... ~~~Steve -- /************************************************* * *Steven Abrams abrams@cs.columbia.edu * **************************************************/ #include <std/dumquote.h> #include <std/disclaimer.h>
williams@umaxc.weeg.uiowa.edu (Kent Williams) (03/13/90)
In article <4296@hub.UUCP> mcm@peach.ucsb.edu (Marcelo C. Mourier) writes: >Hi there! Yo! > I'm having some trouble completing the 1.5.0 upgrade. I have success- > [stuff deleted] >>When make is processing kernel/system.c cpp complains with the following me- >ssage: > > "system.c", line 89: fatal error -- cannot find include file "protect.h" > "./proc.h", line 28: } missing > "./proc.h", line 28: ; missing > >However, file protect.h is indeed present and it has the correct crc. The >same thing happens while make is processing fs/misc.c, cpp complains with: > [more stuff deleted] This is a gotcha that I don't think anyone's posted a note about. The shar files try to include zero length proto.h files in a couple of directories. The shell misses the here-document-end line, and sucks up the rest of the next here-document into proto.h. If you look at proto.h in kernel and fs, you'll find that they contain other files (I don't remember which ones). Unpack them, do a rm proto.h ; touch proto.h to get the proper, zero length proto.h file in kernel and fs, and your problem goes away. Watch out for the binary files in the shell and make shars -- the 1.3 shell silently dies when you try to unpack them, and you need the patches that come after the binary files. I THINK you can edit out the binary files with elle. -- Kent Williams "We're One! All One! Exceptions Eternally? williams@umaxc.weeg.uiowa.edu None! Absolutely None!" - Dr. Bronner's Soap
pcm@iwarp.intel.com (Phil Miller) (03/14/90)
In article <4296@hub.UUCP> mcm@peach.ucsb.edu (Marcelo C. Mourier) writes: >Hi there! > I'm having some trouble completing the 1.5.0 upgrade. I have success- >fully upgraded the include, library, commands, and mm; however, I couldn't >complete the upgrading of the kernel and the fs. Maybe someone who has run >into the same problem could give me a clue of how to solve it. This is >what's happening: >When make is processing kernel/system.c cpp complains with the following me- >ssage: > "system.c", line 89: fatal error -- cannot find include file "protect.h" > "./proc.h", line 28: } missing > "./proc.h", line 28: ; missing Don't know about this one, but read on... >However, file protect.h is indeed present and it has the correct crc. The >same thing happens while make is processing fs/misc.c, cpp complains with: > "misc.c", line 26: fatal error -- cannot find include file "super.h" > "./file.h", line 6: type_identifier missing > "./file.h", line 6: identifier missing > "./file.h", line 6: (warning) no semicolon after declarator > "./file.h", line 6: } missing > "./file.h", line 6: ; missing I had this problem with misc.c, except it wasn't `file.h'. CPP claimed it couldn't find `super.h', even though it's in the very same directory (not to mention the one which lives in /usr/include). >Again, file super.h does exist and has the correct crc. There were no such >problems while making mm; I don't have any idea of what could possibly be >happening... Any suggestions..? Yes. In `misc.c', there are two #include's on lines 24 and 25: #include "param.h" #include "super.h" Reverse them and `misc.c' will build ok. I have NO IDEA why the files do not work as provided. On my system, `misc.c', `fs/super.h', and `param.h' ALL have the correct CRC's, and also the correct protection mode (644), but only this counter-intuitive solution works. I say it is counter-intuitive because I find it difficult to believe that `misc.c' would have been posted without being tested. >Thanks a lot for your time and help. >Marcelo - mcm@cs.ucsb.edu Good luck, Phil ================================================================ -- Phil Miller iWarp Development Program pcm@iwarp.intel.com Intel Corporation Beaverton, Oregon
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (03/14/90)
Complaints about non-existing existent include files nearly always occur as a consequence of too little stack space, use chmem to increase it.
gnf3e@batik.cs.Virginia.EDU (Greg Fife) (03/15/90)
In article <1990Mar14.151243.29980@iwarp.intel.com> pcm@iwarp.intel.com (Phil Miller) writes: >In article <4296@hub.UUCP> mcm@peach.ucsb.edu (Marcelo C. Mourier) writes: > >> I'm having some trouble completing the 1.5.0 upgrade. I have success- >>fully upgraded the include, library, commands, and mm; however, I couldn't >>complete the upgrading of the kernel and the fs. Maybe someone who has run Your compiler is running out of memory. Do a chmem +65000 to each pass of the compiler in /lib or /usr/lib, and give the same treatment to asld in /usr/bin. This may force you to compile with the -F option if you are not doing so already. Greg Fife gnf3e@virginia.edu uunet!virginia!uvacs!gnf3e