Path: utzoo!attcan!uunet!midway!ncar!zaphod.mps.ohio-state.edu!wuarchive!decwrl!sgi!shinobu!odin!harlie.corp.sgi.com!scotth From: scotth@harlie.corp.sgi.com (Scott Henry) Newsgroups: comp.sys.sgi Subject: Re: Swap Partitions (again) Message-ID: <1990Oct24.153915.29502@odin.corp.sgi.com> Date: 24 Oct 90 15:39:15 GMT References: <1990Sep25.132534.16796@cid.aes.doe.CA> <1990Sep25.234622.21252@odin.corp.sgi.com> <1990Oct22.215121.2630@odin.corp.sgi.com> <1308@acf5.NYU.EDU> Sender: news@odin.corp.sgi.com (Net News) Reply-To: scotth@harlie.corp.sgi.com (Scott Henry) Organization: sgi Lines: 76 In article <1308@acf5.NYU.EDU>, sabbagh@acf5.NYU.EDU (sabbagh) writes: |> |> In article <9010201727.AA15683@UZI.MIT.EDU>: |> >I'm trying to build GNU EMACS on a PI. I have successfully built it before |> >on a 4D80, but here I've not been able to successfully do the final temacs |> >statement -- which the PROBLEMS file tells me is because I have insufficient |> >swap space. This seems very possible to me, but I don't know how to increase |> >the amount of swap space I have to complete the compilation. |> >Any descriptions of how swap space works would be appreciated. |> >Thanks, |> >Eugene Gholz |> >(eugholz@athena.mit.edu) |> |> I had this very problem this morning! I have concluded that it is yet |> another "feature" of IRIX 3.3.1. In the past, I was able to build |> emacs 18.52 on a Personal Iris under 3.2. Unfortunately, due to an |> extremely bad installation procedure (another story) and minimal back up |> (my fault) I had to rebuild emacs under 3.3.1; there was not enough |> swap space. I think that I should have posted, instead of just e-mailing so as to stop the propogation of rumours. Here's the scoop on GNU Emacs and Irix 3.3+ (a subset of something I posted a month or so ago): Between 3.2.* and 3.3, the loader no longer ignored errors in the a.out header that GNU Emacs took advantage of. I am told that that was un-done in 3.3.1. It mostly meant that a _stripped_ 3.2 binary would fail to load under 3.3, an unstripped one would appear to work fine. In addition, a change was made in libc.a for POSIX compliance: getwd() was defined, but in terms of getcwd() (or something like that). Emacs assumes by default that a system doesn't have getcwd(), and defines one interms of getwd(). Hence, an inifinite recursion loop is generated, and Emacs (temacs) core-dumps when it hits process limits while building the final executable (xemacs & emacs-18.55.??). 2 solutions: 1) Get 18.56 (should be available any day now, I understand) -- I tested it to ensure that it compiles out-of-the-box under 3.3.1. 2) Add the following lines to either .../src/config.h or .../src/m-iris-4d.h: /* * Irix 3.3 defines this, and causes an infinite loop when trying to dump. */ #define HAVE_GETWD and (if you are running 3.3 instead of 3.3.1), apply the following patch to .../src/unexmips.c (a 1-line change): *** unexmips.c.orig Thu Jan 12 16:14:05 1989 --- unexmips.c Mon Jul 30 22:10:10 1990 *************** *** 255,261 **** rdata_section->s_size = data_start - DATA_START; data_section->s_vaddr = data_start; data_section->s_paddr = data_start; ! data_section->s_size = brk - DATA_START; data_section->s_scnptr = rdata_section->s_scnptr + rdata_section->s_size; vaddr = data_section->s_vaddr + data_section->s_size; scnptr = data_section->s_scnptr + data_section->s_size; --- 255,261 ---- rdata_section->s_size = data_start - DATA_START; data_section->s_vaddr = data_start; data_section->s_paddr = data_start; ! data_section->s_size = brk - data_start; data_section->s_scnptr = rdata_section->s_scnptr + rdata_section->s_size; vaddr = data_section->s_vaddr + data_section->s_size; scnptr = data_section->s_scnptr + data_section->s_size; *** s-irix3_3.h.orig Mon Jul 30 22:10:10 1990 --- s-irix3_3.h Mon Jul 30 23:04:30 1990 *************** -- Scott Henry / Traveller on Dragon Wings Information Services, / Help! My disclaimer is missing! Silicon Graphics, Inc / 'Under-achiever and proud of it!' -- Bart Simpson