🚀 go-pugleaf

Newsgroups: gnu.emacs.help,gnu.emacs.bug
Subject: Help! Installing 18.57 on Amdahl UTS 2.1 with Extended File System
Summary: Can't get it to work with Expanded Fundamental Types
Expires:
Sender:
Reply-To: matthews@asd2.jsc.nasa.gov (Michael C. Matthews)
Followup-To:
Distribution:
Organization: NASA/JSC Engineering Computation Facility
Keywords: UTS Amdahl EFT EFS

Hardware: Amdahl 5990

Software: Emacs 18.57.nnn
          UTS 2.1
          Extended File System
          Expanded Fundamental Types

Our facility recently upgraded to UTS 2.1 on our Amdahl (from UTS 1.2),
and implemented the new Extended File System feature on a couple of our
disks.  Among other things, EFS allows inode numbers beyond 65535 (the
previous limit).

We've been running GNU Emacs 18.54 with no problems for over a year. As
the intrepid soul who got Emacs running on our Amdahl, I was foolish
enough to volunteer to provide local support for it.

Well, the day after they put EFS on one of our disks, I got a call from
the help desk saying that they had complaints that people on that disk
were unable to edit certain files with Emacs.  They had no problem with
vi or any of the system utilities, just Emacs, and to top it off, they
could edit the afflicted files with Emacs if they copied them to another
disk first.  After poking around a bit on the EFS disk, I discovered that
all the files that Emacs couldn't handle had inode numbers in the 70000
range... all the others were below 60000 and could be edited by Emacs.

After some research I came to the conclusion that I needed to recompile
Emacs with the -eft option (on UTS 2.1 cc(1)), so that the Expanded
Fundamental Types would be used.  The -eft flag sets the EFT preprocessor
macro, which is used by the system header files to set up the types for
all the system parameters, many of which need to be bigger to handle the
Extended File System.  Simple, I figured.

So, I configure 18.57 to compile the "old fashioned" way -- without EFT.
(note that UTS 2.1 is based on SysV.3, so I used s-usg5-3.h and twiddled
a few preprocessor definitions, instead of using s-usg5-2-2.h like the
MACHINES doc said... ) Everything goes fine: temacs is made, and xemacs
is dumped, and the dumped xemacs works like a champ (except, of course,
that it can't see the "extended" files on the EFS disk).  So I then modify
the configuration to use cc -eft.  Make.  Compiles temacs, dumps xemacs.
"Great!", I think.

Run xemacs... No dice.  "Illegal instruction(coredump)"

Okay, so I figure that enough is different with the -eft to make the unexec
stuff not work right to dump the xemacs, so I try running temacs -l loadup.

Well, temacs sort of works.  It can load macros, and can open some small files.
However, if I try to find-file on anything over about 4K bytes, I get
"IO error reading /aed/matthews/utils/emacs/eft1857/src/alloc.c: Bad address"

So, I guess I was a little naive in my assumptions about what it takes to
make Emacs EFT/EFS-compatible.  In the last 5 days I've gotten bleary-eyed
stepping through the debugger and looking up macro definitions, and I've
had to learn far more about the internals of Emacs and UTS that I ever
had any intention to.

Please, if there's anybody who has gotten Emacs (any version!) running on
an Amdahl UTS 2.1 system with EFT and EFS, or who has an idea of how messy
the changes might have to be to get it running, or who can give me any references
to people or information about this, contact me via email or followup.

Any help or hints you can give me would be greatly appreciated!

Mike Matthews  (713) 333-7079                    matthews@asd2.jsc.nasa.gov
Tethered Vehicle Analysis, Advanced Systems Group
Navigation, Control, and Aeronautics Department
Engineering and Science Program
Lockheed Engineering and Sciences Company, Houston, TX