From:	CRDGW2::CRDGW2::MRGATE::"SMTP::PREP.AI.MIT.EDU::INFO-GNU-EMACS-REQUEST"  4-OCT-1989 19:49
To:	MRGATE::"ARISIA::EVERHART"
Subj:	Re: Can't bring up emacs on a DECstation 3100

Received: by life.ai.mit.edu (4.1/AI-4.10) id AA02836; Wed, 4 Oct 89 00:25:02 EDT
Return-Path: <info-gnu-emacs-request@prep.ai.mit.edu>
Received: from AENEAS.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA02337; Tue, 3 Oct 89 23:56:54 EDT
Received: from [128.146.8.60] by AENEAS.MIT.EDU (5.61/4.7) id AA27290; Tue, 3 Oct 89 21:47:57 -0400
Received: by tut.cis.ohio-state.edu (5.61/4.890927)
	id AA14718; Tue, 3 Oct 89 21:34:26 -0400
Received: from USENET by tut.cis.ohio-state.edu with netnews
	for info-gnu-emacs@prep.ai.mit.edu (info-gnu-emacs@prep.ai.mit.edu)
	(contact usenet@tut.cis.ohio-state.edu if you have questions)
Date: 3 Oct 89 15:28:32 GMT
From: eru!luth!sunic!mcsun!tuvie!inst182@bloom-beacon.mit.edu  (Inst.f.Techn.Informatik)
Organization: TU Vienna EDP-Center, Vienna, AUSTRIA
Subject: Re: Can't bring up emacs on a DECstation 3100
Message-Id: <732@tuvie>
References: <342@massey.ac.nz>
Sender: info-gnu-emacs-request@prep.ai.mit.edu
To: info-gnu-emacs@prep.ai.mit.edu

In article <342@massey.ac.nz>, KSpagnol@massey.ac.nz (Ken Spagnolo) writes:
> We have a few of those fancy new DECstation 3100 RISC machines running
> Ultrix 3.0.  Below is part of the output when making version 18.51
    [some lines deleted]
> Dumping under names xemacs and emacs-18.51.15
> unexec: 7 sections instead of 6.
> unexec: .lit8 section where .sdata expected.
> *** Error code 1

Well, I experienced the same problem. 
(Emacs version 18.50, part of the `leif' incremental parser 
distribution from uiuc).
After looking at the a.out header of temacs I decided to hack 
the unexec.c-file to cater for the lit8-section. 
After that everything worked fine. That means: xemacs
was dumped without complaint and I was able to run it. I have
not tested it thoroughly, because I don't know much about emacs.
But: It ran until I found someone who told me how to get out! :-)

I thought I might post the diffs. If anyone who *really* knows
what goes on here would like to comment, please do so.

You know, this *must* be the most unofficial patch ever ;-)
No guarantees that this will work, no guarantees it will not do harm etc.

Replies, comments, explanations: See the address *below*.

-alex
Alexander Vrchoticky, TU Vienna.
alex@vmars.at  vmars!alex@uunet.UU.NET

--cut here-- --cut here-- --cut here-- --cut here-- --cut here-- --cut here--

*** unexec.c-dist	Tue Oct  3 14:38:01 1989
--- unexec.c	Tue Oct  3 16:05:44 1989
***************
*** 958,963 ****
--- 958,964 ----
      struct scnhdr text_section;
      struct scnhdr rdata_section;
      struct scnhdr data_section;
+     struct scnhdr lit8_section;
      struct scnhdr sdata_section;
      struct scnhdr sbss_section;
      struct scnhdr bss_section;
***************
*** 1014,1021 ****
        exit(1);
    }
  #endif
!   if (hdr.fhdr.f_nscns != 6) {
!       fprintf(stderr, "unexec: %d sections instead of 6.\n", hdr.fhdr.f_nscns);
    }
  #define CHECK_SCNHDR(field, name, flags) \
    if (strcmp(hdr.field.s_name, name) != 0) { \
--- 1015,1022 ----
        exit(1);
    }
  #endif
!   if (hdr.fhdr.f_nscns != 7) {
!       fprintf(stderr, "unexec: %d sections instead of 7.\n", hdr.fhdr.f_nscns);
    }
  #define CHECK_SCNHDR(field, name, flags) \
    if (strcmp(hdr.field.s_name, name) != 0) { \
***************
*** 1030,1035 ****
--- 1031,1037 ----
    CHECK_SCNHDR(text_section,  _TEXT,  STYP_TEXT);
    CHECK_SCNHDR(rdata_section, _RDATA, STYP_RDATA);
    CHECK_SCNHDR(data_section,  _DATA,  STYP_DATA);
+   CHECK_SCNHDR(lit8_section,  _LIT8,  STYP_LIT8);
    CHECK_SCNHDR(sdata_section, _SDATA, STYP_SDATA);
    CHECK_SCNHDR(sbss_section,  _SBSS,  STYP_SBSS);
    CHECK_SCNHDR(bss_section,   _BSS,   STYP_BSS);
--cut here-- --cut here-- --cut here-- --cut here-- --cut here-- --cut here--
