Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!clyde!cbosgd!soma!masscomp-request
From: smh@mit-amt.MEDIA.MIT.EDU (Steven Haflich)
Newsgroups: comp.sys.masscomp
Subject: Re: GnuEmacs on Masscomp
Message-ID: <3132@soma.bcm.tmc.edu>
Date: Tue, 9-Jun-87 12:33:55 EDT
Article-I.D.: soma.3132
Posted: Tue Jun  9 12:33:55 1987
Date-Received: Fri, 12-Jun-87 05:31:16 EDT
References: <890@fmsrl7.UUCP>
Sender: masscomp@soma.bcm.tmc.edu
Reply-To: media-lab.MEDIA.MIT.EDU!mit-amt!smh (Steven Haflich)
Distribution: world
Organization: MIT Media Lab, Cambridge MA
Lines: 55
Approved: masscomp@soma.bcm.tmc.edu


[It has been reported that current Gnu Emacs fails on Masscomp RTU.]

I have successfully brought up Gnu 18.44 on Masscomp 3.1 RTU with both
the 1.1 and 1.2 versions of the C compiler.  There are a couple
necessary bug workarounds, and I am in the process of submitting bug
reports to Masscomp.  Meanwhile, here's what you have to do:

There is a bug regarding register variables and alloca that is hard to
work around because the compiler tries to be so clever.  [I defer
describing it here.]  This causes the failure of regex searching
during inc-vers, as you described.  One way to workaround would be to
change the *name* of the Gnu-provided fake alloca routine, but I
solved it expediently (if inelegantly) by removing all register
variables.  Put this line in m-masscomp.h:

	#define register

This effectively removes all register declarations.  When you recompile
there will be several modules in the source that contain register
declarations without type specifier, i.e.:

	register foo;

When the compile reports these errors, just change the source to the
equivalent:

	register int foo;

This fixes the problem, and a single-user 68020 is so fast you won't
notice the lack of register variables.

There are two other fixes you might want to make while you are at it.

The current C compiler proprocessor doesn't predefine the variable
MASSCOMP, but some Gnu code conditionalizes on it.  Add to s-rtu.h:

	#define MASSCOMP

There is apparently a bug in Masscomp's implementation of the fsync(2)
system call.  I haven't isolated the bug completely but suspect that
if an inode to be fsync'd is in the same disk block as another `dirty'
inode (or maybe the parant directory) then the entire file system
locks up, requiring reboot.  This can happen when Gnu first writes any
particular file.  The fix is simply to conditionalize out the fcntl in
fileio.c, which is no big deal since fcntl doesn't do anything
detectable to user code in the first place.

With these three changes (and the minor include file hacking you
mentioned) Gnu 18.44 comes up and runs with no problems.

Steve Haflich
smh@ems.mit.edu
Experimental Music Studio, MIT Media Lab
(617)893-8863