Xref: utzoo unix-pc.general:3938 comp.sys.att:7861
Path: utzoo!attcan!utgpu!watmath!uunet!ncrlnk!ncratl!kong!emory!ctrsol!ginosko!usc!srhqla!kosman!kevin
From: kevin@kosman.UUCP (Kevin O'Gorman)
Newsgroups: unix-pc.general,comp.sys.att
Subject: Re: problems with gcc - out of virtural memory
Message-ID: <1004@kosman.UUCP>
Date: 23 Oct 89 05:00:19 GMT
References: <1989Oct21.174252.16142@ivucsb.sba.ca.us> <89@venice.SEDD.TRW.COM>
Reply-To: kevin@kosman.UUCP (Root)
Followup-To: unix-pc.general
Organization: K.O.'s Manor - Vital Computer Systems, Oxnard, CA 93035
Lines: 35

In article <89@venice.SEDD.TRW.COM> baur@venice.SEDD.TRW.COM (Steven L. Baur) writes:
>From article <1989Oct21.174252.16142@ivucsb.sba.ca.us>, by todd@ivucsb.sba.ca.us (Todd Day):
>> I was running gcc for the first time, compiling the latest version
>> of NetHack.  ...
>> So what is the problem?  Does gcc really hog that much memory?
>> Todd Day  |  todd@ivucsb.sba.ca.us  |  ivucsb!todd@anise.acc.com
>
>
>I tried compiling nethack with gcc too, but ran into different problems.
>I have a UNIXPC with 2.5MB of ram and a 62MB winchester.  It compiled and
>linked (apparently) O.K.
>However, when I tried to save/restore levels or arrive on a bones level it
>bombed.
>I finally used stock cc and that got it running.
>
>How much swap space do you have?

Well, I have nethack 3.0 compiled on gcc.  I'm running 2.5 MB in a 3b1 with
System 3.51 and gcc 1.35.  I have a standard "multi-user" swap partition
(6000 blocks, I think).  The only trouble I had was the save/restore problem,
which I tracked down to a crok in as(1)!!!  Seems that gcc in ANSI mode
can put 'const' things in the text partition so that they're memory
protected and shared, but as has a problem with this.  When gcc emits
the 'space' pseudo-op in the text partition, as produces non-zero contents.

This is only a problem for one variable in decl.c, which defines a variable
which it expects to be all zeroes, and which is used to write zeroed
structures as an end-flag in the save-file.

I'm told that gcc 1.36 has this fixed so that it emits explicit data because
of this crok.  Can't blame as too much, because it was never designed for
that sort of thing, but it's annoying anyway.

You can either compile decl.c with -traditional or do the whole shebang
that way to get it compiled with gcc.