Subject: cc1 fails silently From: "LCDR Michael E. Dobson" <rdc30@nmrdc1.nmrdc.nnmc.navy.mil> To: linux-activists@joker.cs.hut.fi (Linix Mailing LIst) Date: Wed, 4 Dec 91 13:01:58 EST Today when I had some time I wanted to try installing a pager and some library routines. Imagine my surprise when nothing would compile! I could not even get the very simple fixit.c program to compile, even gcc -c fixit.c -o fixit.o produced nothing!! Using gcc -v and manually running the indiviual steps, it seems cc1 is failing silently, ie, if I run the cc1 command from gcc -v on the output from cpp, I get no .s file produced! This all used to work fine for me, I was even able to build the recently posted mawk with little effort. Does anyone have a clue as to what is going on? I'd like to get this solved so I can get less up and move on to bigger things. I'm looking to see what needs to be done to the posix/stdc lib routines that came with the new pdksh sources. THey look to have at least a complete string package which means I can then tackle uucp/mail/news. Any suggestions greatly appreciated. -- Mike Dobson, Sys Admin for | Internet: rdc30@nmrdc1.nmrdc.nnmc.navy.mil nmrdc1.nmrdc.nnmc.navy.mil | UUCP: ...uunet!mimsy!nmrdc1!rdc30 AT&T 3B2/600G Sys V R 3.2.2 | BITNET: dobson@usuhsb or nrd0mxd@vmnmdsc WIN/TCP for 3B2 | MCI-Mail: 377-2719 or 0003772719@mcimail.com
Subject: Re: cc1 fails silently Date: Wed, 4 Dec 1991 21:13:38 +0200 From: Linus Benedict Torvalds <torvalds@cc.helsinki.fi> In-Reply-To: "LCDR Michael E. Dobson"'s message as of Dec 4, 13:01 To: "LCDR Michael E. Dobson" <rdc30@nmrdc1.nmrdc.nnmc.navy.mil>, "LCDR Michael E. Dobson": "cc1 fails silently" (Dec 4, 13:01): > Today when I had some time I wanted to try installing a pager and some > library routines. Imagine my surprise when nothing would compile! I could > not even get the very simple fixit.c program to compile, even gcc -c > fixit.c -o fixit.o produced nothing!! Using gcc -v and manually running > the indiviual steps, it seems cc1 is failing silently, ie, if I run the cc1 > command from gcc -v on the output from cpp, I get no .s file produced! > This all used to work fine for me, I was even able to build the recently > posted mawk with little effort. Does anyone have a clue as to what is > going on? cc1 failing silently is usually due to out of memory errors, but as it worked for you before, that probably isn't it. The only other solution I can come up with is kernel bugs :-(. It seems there are a few race-conditions left in 0.10, which can cause filesystem errors. The worst of these was fixed with the new buffer.c, and if you don't have the updated binaries, filesystem errors are a certainty after a while (unless you are very lucky). Fsck is not (and never will be) able to find errors that have creapt in into the data-blocks of files - and as cc1 is the biggest binary linux uses, that's the one most likely to catch these errors. There was another race-condition I found only yesterday, but it shouldn't cause too many problems, especially not for harddisks. That one will be corrected in 0.11 (countdown: 4-5 days). I'm not even certain this one can ever happen. I'd suggest you verify your binary, and you might even upgrade to the gcc-cc1 that understands floats with exponents, available from Tupac-Amaru (incoming). If that doesn't cut it, I'd be interested in what changes you have made to your hardware/system? Linus
Subject: Re: cc1 fails silently From: "LCDR Michael E. Dobson" <rdc30@nmrdc1.nmrdc.nnmc.navy.mil> To: linux-activists@joker.cs.hut.fi (Linix Mailing LIst) Date: Wed, 4 Dec 91 15:50:07 EST In-Reply-To: <9112041942.AA05005@tsx-11.MIT.EDU>; from "Theodore Ts'o" at Dec 4, 91 2:42 pm In response to my question about cc1 failing silently I received the following: > > Date: Wed, 4 Dec 1991 21:13:38 +0200 > From: Linus Benedict Torvalds <torvalds@cc.helsinki.fi> > > cc1 failing silently is usually due to out of memory errors, but as it > worked for you before, that probably isn't it. The only other solution > I can come up with is kernel bugs :-(. > From: <9112041942.AA05005@tsx-11.MIT.EDU>; from "Theodore Ts'o" at Dec 4, 91 2:24pm > Have you checked to see if you've filled your hard disk? This is > somewhat hard to check since there's no df utility. You can find out > the number of free blocks of your root partition at boot time, though. > It appears you both were wrong and it is something more trouble, possibly related to the race conditions Linus mentioned, but more likely some subtle kernel bugs. I forgot to mention I received a swapper panic when I soft booted from DOS the first time and just redid the soft boot. Just a few minutes ago I did a hard boot (ie hit the reset button) and saw the following at bootup: Partiton table ok. 5278/9860 free blocks 2798/3294 free inodes 507 buffers = 519168 bytes free buffer space Free mem: 3145728 bytes Ok. bash# A "du" on / gave 8423 /. The best part is that gcc now works just fine!! However, the make of less failed because I don't have a sgtty.h Will grab the Minix version and see what develops. It's also looking for libtermcap.a but we'll see ;-) Regards, -- Mike Dobson, Sys Admin for | Internet: rdc30@nmrdc1.nmrdc.nnmc.navy.mil nmrdc1.nmrdc.nnmc.navy.mil | UUCP: ...uunet!mimsy!nmrdc1!rdc30 AT&T 3B2/600G Sys V R 3.2.2 | BITNET: dobson@usuhsb or nrd0mxd@vmnmdsc WIN/TCP for 3B2 | MCI-Mail: 377-2719 or 0003772719@mcimail.com
Subject: Re: cc1 fails silently Date: Wed, 4 Dec 91 21:13:22 -0500 From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) To: "LCDR Michael E. Dobson" <rdc30@nmrdc1.nmrdc.nnmc.navy.mil> Cc: linux-activists@joker.cs.hut.fi In-Reply-To: LCDR Michael E. Dobson's message of Wed, 4 Dec 91 15:50:07 EST, Reply-To: tytso@athena.mit.edu It appears you both were wrong and it is something more trouble, possibly related to the race conditions Linus mentioned, but more likely some subtle kernel bugs. Well, maybe. The swapper panic which happens after you type ctrl-alt-del from DOS is standard in Linux 0.10 --- it's harmless, and typing ctrl-alt-del after the panic will allow Linux to boot successfully. Partiton table ok. 5278/9860 free blocks 2798/3294 free inodes 507 buffers = 519168 bytes free buffer space Free mem: 3145728 bytes Ok. bash# A "du" on / gave 8423 /. Remember that "du" outputs sizes in 512 byte blocks, courtesy of POSIX. My personal opinion is that it's one of the stupidest mistakes POSIX has committed, since most users care about file sizes in kilobytes, not in 512 byte blocks --- but then, I can alias du to "du -k", so the only losers are the innocent, naive users. [End of soapbox] With that said, you may have a problem, but it looks like the standard corrupted filesystem problem that happens when you are using a stock, unpatched version of Linux 0.10. The number of free blocks as caluclated by the "du" is (9860 - 8423/2) = 5644, which is larger than 5278, but only by 366k. I've seen that sort of lossage on the stock Linux 0.10, and I haven't seen it once the bug fix to buffer.c was applied. - Ted
Subject: Re: cc1 fails silently Date: Thu, 5 Dec 1991 05:15:29 +0200 From: Linus Benedict Torvalds <torvalds@cc.helsinki.fi> In-Reply-To: Theodore Ts'o's message as of Dec 4, 21:13 To: tytso@athena.mit.edu, Cc: linux-activists@joker.cs.hut.fi Theodore Ts'o: "Re: cc1 fails silently" (Dec 4, 21:13): > > With that said, you may have a problem, but it looks like the standard > corrupted filesystem problem that happens when you are using a stock, > unpatched version of Linux 0.10. The number of free blocks as > caluclated by the "du" is (9860 - 8423/2) = 5644, which is larger than > 5278, but only by 366k. I've seen that sort of lossage on the stock > Linux 0.10, and I haven't seen it once the bug fix to buffer.c was > applied. It does seem so, but always remeber that du doesn't count blocks exactly: it uses a heuristic algorithm that doesn't work on sparse files etc. I'd still check the filesystem - that's the most likely problem. And then over to happier things: here's sources to mount and umount, as corsini wanted something that keeps track of mounted devices, and as I couldn't find anything more interesting to do I just hacked these together . These versions keep the file "/etc/mtab" up-to-date, just like real mount/umount should do. You can certainly confuse them, but they are a bit better than nothing. This is a 1/2 hour hack, so don't expect wonders, but my limited testing hasn't shown any problems yet. /etc/mtab will later be needed for "df", but as ustat isn't implemented yet, df won't work. Oh well. Meanwhile you can get mount-info by "cat /etc/mtab". Linus Code
Subject: Re: cc1 fails silently From: "LCDR Michael E. Dobson" <rdc30@nmrdc1.nmrdc.nnmc.navy.mil> To: tytso@athena.mit.edu Date: Thu, 5 Dec 91 8:37:35 EST Cc: linux-activists@joker.cs.hut.fi (Linix Mailing LIst) In-Reply-To: <9112050213.AA05299@tsx-11.MIT.EDU>; from "Theodore Ts'o" at Dec 4, 91 9:13 pm I previously said: > > It appears you both were wrong and it is something more trouble, possibly > related to the race conditions Linus mentioned, but more likely some > subtle kernel bugs. > To which Ted responded: > Well, maybe. The swapper panic which happens after you type > ctrl-alt-del from DOS is standard in Linux 0.10 --- it's harmless, and > typing ctrl-alt-del after the panic will allow Linux to boot > successfully. > Depends what you mean by successfully. If I can't run gcc after ctrl-alt-del boot, I don't consider the boot successfull. Remember, I said the cc1 failure disappeared when I did a hard boot, I did nothing else to the system, did not reload the gcc binaries nor mkfs a new system. Now I suppose it is therefore the in core image of the file system that was corrupted and not the hard disk fs itself. I haven't attempted to build a linux kernel myself yet so I didn't apply the buffer.c patch, will wait for 0.11 which will be able to compile itself without using Minix or some other OS. Ted then pointed out: > Remember that "du" outputs sizes in 512 byte blocks, courtesy of POSIX. > My personal opinion is that it's one of the stupidest mistakes POSIX > has committed, since most users care about file sizes in kilobytes, not > in 512 byte blocks --- but then, I can alias du to "du -k", so the only > losers are the innocent, naive users. [End of soapbox] > Guess it's time to set up a "proper" .profile with a few aliases in it ;-) Anyone know why the default TERM is "dumb" instead of "console"? BTW, once gcc was working, I successfully built less using only #define TERMIO 1 #define REGCMP 0 #define RECOMP 0 in defines.h and removing the reference to libtermcap.a in the Makefile. I also was able to compile all the stdc routines from the pdksh src with the exception of setvbuf.c, stdio.c (probably not needed) and vprintf.c. I had to change the #include "stdh.h" to #include <string.h> in strstr.c and one of the mem*.c routines. Anyone got a good exerciser for the mem* and str* routines? These could be very useful additions to the Linux libc.a NOTE, I used the *.h files that came with pdksh. -- Mike Dobson, Sys Admin for | Internet: rdc30@nmrdc1.nmrdc.nnmc.navy.mil nmrdc1.nmrdc.nnmc.navy.mil | UUCP: ...uunet!mimsy!nmrdc1!rdc30 AT&T 3B2/600G Sys V R 3.2.2 | BITNET: dobson@usuhsb or nrd0mxd@vmnmdsc WIN/TCP for 3B2 | MCI-Mail: 377-2719 or 0003772719@mcimail.com
Subject: Re: cc1 fails silently Date: Thu, 5 Dec 91 14:17:06 -0500 From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) To: "LCDR Michael E. Dobson" <rdc30@nmrdc1.nmrdc.nnmc.navy.mil> Cc: linux-activists@joker.cs.hut.fi Reply-To: tytso@athena.mit.edu From: "LCDR Michael E. Dobson" <rdc30@nmrdc1.nmrdc.nnmc.navy.mil> Date: Thu, 5 Dec 91 8:37:35 EST corrupted and not the hard disk fs itself. I haven't attempted to build a linux kernel myself yet so I didn't apply the buffer.c patch, will wait for 0.11 which will be able to compile itself without using Minix or some other OS. Do you know about about TSX-11.MIT.EDU, or some of the other anonymous FTP sites? There are precompiled boot images of Linux 0.10 which have the patched buffer.c. There's also a pre-compiled image of less there already. You might want to look around; there's binaries for kermit, Bison (yacc), flex (lex), RCS, etc. Might help you from reiventing the wheel. :-) I also was able to compile all the stdc routines from the pdksh src with the exception of setvbuf.c, stdio.c (probably not needed) and vprintf.c. I had to change the #include "stdh.h" to #include <string.h> in strstr.c and one of the mem*.c routines. Anyone got a good exerciser for the mem* and str* routines? These could be very useful additions to the Linux libc.a NOTE, I used the *.h files that came with pdksh. I believe the Linux libc.a already contains the mem* and str* routines, using the GNU libc routines. At least, the libc.a included in gccbin.tar.Z already has those routines. - Ted