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