Xref: utzoo comp.sys.ibm.pc.rt:164 comp.emacs:4499 gnu.emacs:132
Path: utzoo!utgpu!attcan!telly!ddsw1!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!agate!bionet!apple!bloom-beacon!tut.cis.ohio-state.edu!triceratops.cis.ohio-state.edu!karl
From: karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste)
Newsgroups: comp.sys.ibm.pc.rt,comp.emacs,gnu.emacs
Subject: Re: Gnu Emacs v18.44 on RT
Message-ID: <25394@tut.cis.ohio-state.edu>
Date: 21 Oct 88 20:05:26 GMT
References: <919@cps3xx.UUCP>
Sender: news@tut.cis.ohio-state.edu
Distribution: usa
Lines: 22
In-reply-to: usenet@cps3xx.UUCP's message of 21 Oct 88 18:37:34 GMT

Any SysVish system which runs temacs fine and gives you an xemacs, but
which then follows an attempt to execute xemacs with
	Killed
is almost certainly a victim of COFF troubles.  The SysV kernel
(especially back on VAX USG V.2) does not provide much in the way of
decent error-checking as it loads in a binary, and if it detects
formatting troubles in the COFF headers, it takes the wholly rude
solution of
	psignal(p, SIGKILL);
which is why you hear about it from the shell as just `Killed.'

Acknowledging that I've never built GNU Emacs on an RT, I would first
suggest that you #define NO_REMAP and try it all over again.  This
will tell unexec() not to be nearly so, ahem, creative in how it
futzes about with the boundaries of text and data space, thus reducing
the likelihood of upsetting COFF issues.

Alternatively, of course, pick the most recent version (18.52) from
wherever is most convenient and try that.

coff, coff, choke.

--Karl