Path: utzoo!utgpu!watmath!uunet!tut.cis.ohio-state.edu!LUCID.COM!lnz
From: lnz@LUCID.COM (Leonard N. Zubkoff)
Newsgroups: gnu.emacs.bug
Subject: Re:  GNU emacs for Apollo: any luck?
Message-ID: <8903172235.AA00325@atlantis>
Date: 17 Mar 89 22:35:24 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 50


Hmmm.  This sounds vaguely familiar.  What version of C Compiler are you
running?  The SR9.7 C Compiler worked correctly, but the SR9.7.1 C Compiler
had a bug which prevented it from working with Emacs, though I cannot
remember the exact manifestation.

I will shortly be releasing a new set of modifications for 18.53.  The new
version will not require AEGIS /sys/ins files; it will build on the native
bsd4.3 environment.  I also will build on the DN10000, and there is an
easy procedure for distributing compound executables that run on both the
68020/68030 machines and PRISM machine (DN10000).

                Leonard N. Zubkoff
                Lucid, Incorporated

    From eichin@athena.mit.edu Fri Mar 17 12:59:09 1989
    Date: Wed, 15 Mar 89 18:43:03 EST
    From: Mark W. Eichin <eichin@athena.mit.edu>
    To: bug-gnu-emacs@prep.ai.mit.edu
    Subject: GNU emacs for Apollo: any luck?

    I've tried building both "apollo-emacs" and "dist-18.53" from prep on
    both DN590 and DN3000 running Domain/OS 9.7, with no success. The
    failure mode: either an immediate crash with Fatal Error
    (apollo-emacs, either on a telnet line or a gpr window), or if I build
    dist-18.53 with HAVE_X_WINDOWS, I can get it to run through loadup
    until it hits lisp-mode, where it dies with "Symbol function
    definition is void: not" with the mode-line all dashes, and no
    apparent response to input (it doesn't actually crash, it has to be
    kicked over.) Running under dbx gives me a dbx and an emacs which are
    > 5Meg each and not doing anything. This is under the bsd4.2
    environment, if it makes a difference (though I assume this is right,
    since config.h uses m-bsd42.h.)

    Therefore, some questions:
	    - Has anyone else succeeded? Any hints?
	    - Why are the options configured for (such as SYSTEM_MALLOC)
    opposite in many cases in apollo-emacs and dist-18.53?
	    - Should I just wait (and wait...) for 10.1? does it work
    there? 

    I actually have a working binary for 17.63, but the sources with it
    don't produce a working emacs (though I narrowed at least 2 of the
    problems down to new compiler bugs in the 9.7 compiler that wern't
    present in the one used for the binary there...)

    Any help would be appreciated (especially since my current strategy is
    "Use a Sun instead" :-)
					    Mark Eichin
					    <eichin@athena.mit.edu>