dennis@beaver.cs.washington.edu (Dennis Gentry) (02/09/88)
I have tried (so far unsuccessfully) to get GNU Emacs 18.49
going on this Masscomp 5600 running RTU 3.1c. I can get a
temacs successfully compiled (but only by adding the C compiler
flag -fsoft or else the linker flag -lflight), but then it dies
in the regexp search code. If I skip the search code (i.e.
inc-vers.el), the bare emacs can load most of the stuff listed
in loadup.el.
The debugger (mdb) variously craps out or not depending on
which printf statements I've included to try to (reliably) find
out the values of variables. This is not good. Also, when I
change the printfs I'm using, not only does mdb work
differently, but the values of variables I'm trying to debug
get modified differently. Finally, the same copy of
temacs behaves differently (internally, not just output-wise)
when piped through less from when the output goes directly to
the screen.
During a make, in the first invocation of temacs (./temacs
-batch -l inc-vers ), there is a regexp search using
"[^"]*[0-9]+" as a pattern to try to match "18.49.0" The
pattern seems to compile o.k., but then it looks like translate
and/or fastmap in re_search_2 get whomped somewhere inside
re_match_2. It depends on whether I "watch" them with printfs
or not. If I watch them, they appear to be o.k. most of the
time. During the first use of translate and fastmap,
they're ok (i.e. before calling re_match_2).
Any Masscomp gurus know anything about weird memory allocation
problems or C compiler bugs? How about any of you veteran
emacs porters out there? Has anyone else seen anything like
this? I thought this had already been done.
I would greatly appreciate any prompt help anyone could give
me.
Thanks.
--
Dennis.
-------
arpa: uw-nsr!uw-warp!dennis@beaver.cs.washington.edu
usenet: {ihnp4|decvax|...}uw-beaver!uw-nsr!uw-warp!dennissdr@mrmarx.UUCP (Stephen D. Rogers) (02/18/88)
In article <3325@soma.bcm.tmc.edu> uw-warp!dennis@beaver.cs.washington.edu (Dennis Gentry) writes: > >I have tried (so far unsuccessfully) to get GNU Emacs 18.49 >going on this Masscomp 5600 running RTU 3.1c. >... I would greatly appreciate any prompt help anyone could give >me. > I have brought up GNU Emacs v17.49, v18.46, and GNU Emacs v18.49 on our Masscomp systems. We are currently running GNU Emacs v18.49. The workarounds to apply to the GNU distribution depend primarily on the version of the C compiler and runtime library that you are using, and somewhat on the release of RTU 3.1 that you are using. I have applied the following workarounds at various times. 1) Several releases of Masscomp's C compiler have trouble with register declarations. Disable register declarations by defining the keyword "register" as an empty macro. For example, "cc -c -Dregister='' foo.c". You will have to fix-up a handful of source files which use, for example, "register i" rather than "register int i". 2) Masscomp's alloca() is broken in some releases. I have successfully used the alloca() "emulator", written in C, which comes with GNU Emacs. 3) Masscomp's fsync() is broken in some (all?) releases. It is only used in one place, in the write-region(?) code in "src/fileio.c". I am currently running with the fsync() call essentially commented out. This is not the best solution, but it works, since RTU flushes its file buffers reasonably often anyway. If you do not disable the call to Masscomp's fsync(), RTU will eventually lock up. The symptoms I have seen involve a file save or an autosave, after which the system load ramps steeply up "forever". 4) Make sure that you compile and link everything in the ucb universe. Even so, a few of the programs in etc/ will not compile due to missing BSD header files. Fortunately, these few programs are not particularly important. There may be other workarounds which I have forgotten, or which I am not aware of. Once you apply the workarounds, GNU Emacs v18.49 works quite nicely on RTU. -- Stephen D. Rogers {uunet,masscomp,alliant}!mrmarx!sdr Decision Software Company 51 Spinelli Place Cambridge, MA 02138