KSpagnol@massey.ac.nz (Ken Spagnolo) (09/29/89)
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 (stuff deleted) ./temacs -batch -l loadup.el dump (stuff deleted) Loading site-load... Loading mu-mods... Loading version.el... Finding pointers to doc strings... Finding pointers to doc strings...done Loading site-init... Dumping under names xemacs and emacs-18.51.15 unexec: 7 sections instead of 6. unexec: .lit8 section where .sdata expected. *** Error code 1 Having no idea what was going on, I consulted the PROBLEMS file and found that fatal errors sometime occur at this stage due to insufficient swap space. We have 60Mb for 24 Mb of RAM, so I'd think we were ok there. However, I've had to guess at which machine and system include files to use. The compile and link phases go fine using s-bsd4-3.h and m-mips.h, but perhaps this is not quite right? (I did have to remove the -lmld on the link; there were no complaints without it.) So has anyone had success bringing it up on one of these beasts? Thanx for any info... -- Ken Spagnolo - Systems Programmer, Postmaster, Usenet Administrator, etc. Computer Centre, Massey University, Palmerston North, New Zealand K.Spagnolo@massey.ac.nz Phone: +64-63-69099 x8587 New Zealand = GMT+12
inst182@tuvie (Inst.f.Techn.Informatik) (10/03/89)
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--