🚀 go-pugleaf

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!dennis