home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / sgi / 16418 < prev    next >
Encoding:
Internet Message Format  |  1992-11-14  |  5.2 KB
  1. Xref: sparky comp.sys.sgi:16418 comp.emacs:3548 gnu.emacs.help:4784
  2. Newsgroups: comp.sys.sgi,comp.emacs,gnu.emacs.help
  3. Path: sparky!uunet!ukma!darwin.sura.net!sgiblab!sgigate!odin!sgi.com!scotth
  4. From: scotth@hoshi.corp.sgi.com (Scott Henry)
  5. Subject: Re: Problem installing emacs on SGI
  6. In-Reply-To: 2064aw@gmuvax2.gmu.edu's message of 13 Nov 92 16: 43:36 GMT
  7. Message-ID: <SCOTTH.92Nov13145741@hoshi.corp.sgi.com>
  8. Sender: news@odin.corp.sgi.com (Net News)
  9. Nntp-Posting-Host: hoshi.corp.sgi.com
  10. Organization: Silicon Graphics Inc, Mountain View, CA
  11. References: <1992Nov13.164336.2832@gmuvax2.gmu.edu>
  12. Date: Fri, 13 Nov 1992 19:57:41 GMT
  13. Lines: 127
  14.  
  15.  
  16. >>>>> In article <1992Nov13.164336.2832@gmuvax2.gmu.edu>, 2064aw@gmuvax2.gmu.edu (R Moxley) writes:
  17.  
  18. 2064aw> I'm having problems installing emacs on our SGI machines.  The
  19. 2064aw> distribution that I have is the one on the toolbox2.1 CD...
  20. 2064aw> it's emacs 18.56.9.  I follow the installation instructions in
  21. 2064aw> the README and README-SGI files, and the compilation seems to
  22. 2064aw> work fine.  However, the command
  23.  
  24. 2064aw>           ./temacs -batch -l loadup.el dump
  25.  
  26. 2064aw> fails at the very end with the following messages:
  27.  
  28. 2064aw>           Dumping under names xemacs and emacs-18.56.9
  29. 2064aw>           unexec: 3 sections found instead of 10.
  30. 2064aw>           *** Termination code 139
  31.  
  32. 2064aw> Investgation reveals that a core file from temacs is left in
  33. 2064aw> the src directory when this happens.  The PROBLEMS file in the
  34. 2064aw> distribution states that a lack of swap space can cause
  35. 2064aw> behavior like this, but I don't think that's our problem --
  36. 2064aw> I've tried to compile on machines with plenty of swap space,
  37. 2064aw> and I get identical problems.  I'm using IRIX Release 4.0.5F.
  38.  
  39. I'm not sure how the Marketing names compare with internal naming, but
  40. I think you've got the 3.1 compilers. The a.out section layout changed
  41. from the 2.* compilers to the 3.1, so unexmips.c needs to be patched
  42. to allow temacs to undump the program. BTW, 18.59 is the latest
  43. version, and may actually have this patch in it.
  44.  
  45. Newsgroups: gnu.epoch.misc
  46. Path: odin!fido!shankar
  47. From: shankar@sgi.com (Shankar Unni)
  48. Subject: Patch for "unexmips.c" (SGI & MIPS)
  49. Message-ID: <p4akar8@fido.asd.sgi.com>
  50. Sender: news@fido.asd.sgi.com (Usenet News Admin)
  51. Organization: Silicon Graphics, Inc.
  52. Date: Fri, 28 Aug 1992 02:25:24 GMT
  53. Lines: 82
  54.  
  55.  
  56. Here is a patch for "unexmips.c" to make it work with the latest
  57. release of SGI compilers (the 3.10 compilers) on the Irix 4.0.5
  58. platform. This should continue to work with the old 2.* compilers as
  59. well as the MIPS compilers.
  60.  
  61. The reasons for this patch:
  62.  
  63.  (a) The order of sections seems to have been changed in the latest
  64.      release. Since we can't rely on the order, we need to linearly scan
  65.      the section list in the header for each section we are interested
  66.      in. Thus, we need to adjust the s_[vp]addr for rdata_section.
  67.  
  68.  (b) The symbol-table is no longer at the end of the file - it now seems
  69.      to be between the text and data sections.  Thus, we need to adjust
  70.      the scnptr for rdata_section, too.
  71.  
  72. ============================== snip snip ==============================
  73. *** unexmips.c.orig    Fri Aug  7 14:36:00 1992
  74. --- unexmips.c    Thu Aug 27 19:10:46 1992
  75. ***************
  76. *** 152,158 ****
  77. --- 152,164 ----
  78.         exit(1);
  79.       }
  80.   
  81. + /*
  82. +  * The headers are no longer in text-init-rdata-data order. Therefore we 
  83. +  * have to do a linear search for each section in the section list.
  84. +  */
  85.   #define CHECK_SCNHDR(ptr, name, flags) \
  86. +   i = 0; ptr = NULL; \
  87. +   while(i < hdr.fhdr.f_nscns && !ptr) { \
  88.     if (strcmp(hdr.section[i].s_name, name) == 0) { \
  89.       if (hdr.section[i].s_flags != flags) { \
  90.         fprintf(stderr, "unexec: %x flags where %x expected in %s section.\n", \
  91. ***************
  92. *** 159,171 ****
  93.             hdr.section[i].s_flags, flags, name); \
  94.       } \
  95.       ptr = hdr.section + i; \
  96. -     i += 1; \
  97.     } \
  98. !   else { \
  99. !     ptr = NULL; \
  100. !     }
  101.   
  102. -   i = 0;
  103.     CHECK_SCNHDR(text_section,  _TEXT,  STYP_TEXT);
  104.     CHECK_SCNHDR(init_section,  _INIT,  STYP_INIT);
  105.     CHECK_SCNHDR(rdata_section, _RDATA, STYP_RDATA);
  106. --- 165,174 ----
  107.             hdr.section[i].s_flags, flags, name); \
  108.       } \
  109.       ptr = hdr.section + i; \
  110.     } \
  111. !   i += 1; \
  112. !   }
  113.   
  114.     CHECK_SCNHDR(text_section,  _TEXT,  STYP_TEXT);
  115.     CHECK_SCNHDR(init_section,  _INIT,  STYP_INIT);
  116.     CHECK_SCNHDR(rdata_section, _RDATA, STYP_RDATA);
  117. ***************
  118. *** 198,203 ****
  119. --- 201,212 ----
  120.   
  121.     hdr.aout.bss_start = hdr.aout.data_start + hdr.aout.dsize;
  122.     rdata_section->s_size = data_start - DATA_START;
  123. + 
  124. +   /* adjust start and virtual addresses of rdata_section, too */
  125. +   rdata_section->s_vaddr = DATA_START;
  126. +   rdata_section->s_paddr = DATA_START;
  127. +   rdata_section->s_scnptr = text_section->s_scnptr + hdr.aout.tsize;
  128. + 
  129.     data_section->s_vaddr = data_start;
  130.     data_section->s_paddr = data_start;
  131.     data_section->s_size = brk - data_start;
  132. ============================== snip snip ==============================
  133.  
  134. --
  135. Shankar Unni                E-Mail:    shankar@sgi.com
  136. Silicon Graphics Inc.            Phone:    +1-415-390-2072
  137.  
  138. --
  139.  Scott Henry <scotth@sgi.com> / Traveller on Dragon Wings
  140.  Networking Services,        / Help! My disclaimer is missing!
  141.  Silicon Graphics, Inc      / GIGO *really* means: Garbage in, Gospel Out
  142.