Xref: utzoo comp.emacs:2912 comp.sys.att:2659
Path: utzoo!mnetor!uunet!wucs1!wucs2!wuccrc!dwex
From: dwex@wuccrc (David Wexelblat)
Newsgroups: comp.emacs,comp.sys.att
Subject: Re: Gnu Emacs 18.4[69] on a 3B2 running 3.1
Message-ID: <791@wucs2.UUCP>
Date: 29 Feb 88 14:44:34 GMT
References: <789@wucs2.UUCP> <7284@tut.cis.ohio-state.edu>
Sender: usenet@wucs2.UUCP
Reply-To: dwex@wuccrc.UUCP (David Wexelblat)
Organization: Washington University
Lines: 31

In article <7284@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes:
>You should check to see that your system's MAXMEM is sufficiently
>large to handle Emacs, and also that the recompiled binary didn't cut
>short due to ulimit braindamage; these 2 things have weird effects on
>the building of Emacs, and either could be your trouble.  We built
>18.49 on 3B2/400s with V.3.0 and have had no trouble.  (We told it to
>believe in 16Mb programs, and 128Mb file ulimit, just because I hate
>arbitrary limits.)
>
>Karl


I should have stated this beforehand.  Emacs dumps OK in both cases
(18.46 and 18.49).  I didn't like the ulimit hack, so I modified ymakefile
to use C_OPTIMIZE_SWITCH (which is the empty string for the 3B2) instead of
C_DEBUG_SWITCH.  This results in a dumped file <1Mb.  There is NO
MAXMEM parameter in /etc/master.d/kernel in V.3.1.  If someone knows what
has become of this parameter, I would appreciate being informed.

ULIMIT is now a configurable parameter in 3.1 (I just noticed), so the
ulimit hack isn't needed.

Also, temacs displays the same problems as the dumped emacs, so the problem
is not caused by unexec.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
David Wexelblat	   Washington University in St. Louis  (314) 889-4794
UUCP:		   dwex@wuccrc.UUCP  or  ..!{ihnp4,uunet}!wucs1!wuccrc!dwex
ARPANET:	   wucs1!wuccrc!dwex@uunet.uu.net
CSNET:		   wucs1!wuccrc!dwex%uunet.uu.net@csnet-relay or
		   wucs1!wuccrc!dwex.uucp%bbncv.ARPA@csnet-relay