wilkes@mips.COM (John Wilkes) (07/03/90)
I recently installed ESIX rev. D, and being new to i386 systems, I have
some questions.
1. I got emacs to make after contacting ESIX tech support for some patches
required for (I believe) shared libraries. However, it is built with
"CANNOT_DUMP" defined, and so must load up a bunch of elisp each time it
starts up. Can anyone provide me with an unexec() for ESIX?
2. Gcc compiles with /bin/cc, but fails to compile itself, apparently
looping when attempting to compile c-parse.tab.c. The stock cc compiles
this particular file pretty quickly, and I let gcc munch on it for over
eight hours. Has anybody gotten gcc to compile itself?
3. Bash will not compile with /bin/cc, complaining of "token too long" in
builtins.c (or something like that, I forget the exact file name.) Looks
like it chokes on a very long string constant. I haven't really tried gcc
on bash, due to the problem described in #2 above.
4. Less will not compile. Looks like the same sort of confusion emacs had
before the ESIX patches were applied. It is probably a slightly old
version of less. Any hints? (I will admit to not having tried real hard,
and my ESIX technical documentation set is sitting in the car at this very
moment. I may find the answer when I break open the manuals.)
5. What is "shadow ram" and do I want it enabled? As I said, I am new to
i386 based systems, and I'm blissfully ignorant of the MS-DOS world.
Anyone who wishes to contribute to my education will earn my undying
gratitude.
Some general comments about ESIX. Rev D has the Berkeley Fast File System
as the default. My 25MHz 4MB system seems pretty snappy, but I have no
experience with previous ESIX releases, so I cannot comment on file system
performance improvements from FFS. The ESIX FFS does *not* give you file
names longer than 14 characters, nor does it offer symbolic links.
I had a problem or two with X, both related to my own brain damage and
subsequent pilot error, and ESIX tech support was very helpful. And they
didn't charge me for it. ;-) Now, if I could just find online man pages,
nroff, and ksh, I'd be happy!
--
John Wilkes
wilkes@mips.com -OR- {ames, decwrl, pyramid}!mips!wilkespcg@cs.aber.ac.uk (Piercarlo Grandi) (07/04/90)
In article <39864@mips.mips.COM> wilkes@mips.COM (John Wilkes) writes:
1. I got emacs to make after contacting ESIX tech support for some patches
required for (I believe) shared libraries. However, it is built with
"CANNOT_DUMP" defined, and so must load up a bunch of elisp each time it
starts up. Can anyone provide me with an unexec() for ESIX?
You should be using the standard COFF unexec. It should work...
2. Gcc compiles with /bin/cc, but fails to compile itself, apparently
looping when attempting to compile c-parse.tab.c. The stock cc compiles
this particular file pretty quickly, and I let gcc munch on it for over
eight hours. Has anybody gotten gcc to compile itself?
You must have at least 4 megabytes of memory to run gcc with the
optimizer on. Gcc grows to several megs, and has very poor locality, and
gets paged. Worse, it gets swapped mercilessly because of a mistake in
the ESIX swapper algorithm.
Most importantly it is *vital* that you do not use the alloca() emulation
written in C. Use the alloca() in -lPW, and do stage1 using cc with
'-O -W2,-y0'. The C alloca() emulation uses up an immense amount of
memory.
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukpozar@kumr.UUCP (Tim Pozar) (07/05/90)
In article <39864@mips.mips.COM> wilkes@mips.COM (John Wilkes) writes: >I recently installed ESIX rev. D, and being new to i386 systems, I have >some questions. > >1.[...] > >Now, if I could just find online man pages, >nroff, and ksh, I'd be happy! ^^^^^ I had the same problem. I wanted to print/display (n,t,etc.)roff documents. ESIX has no support for this. I found a very nice nroff and laser printer support package called Xroff. It is put out by image network. The folks there were very nice in describing their product and shiping it out. You can give them a call at 415-967-0542. Tim -- Tim Pozar Try also... uunet!hoptoad!kumr!pozar Fido: 1:125/555 PaBell: (415) 788-3904 USNail: KKSF-FM / 77 Maiden Lane / San Francisco CA 94108
david@csource.oz.au (david nugent) (07/06/90)
In <PCG.90Jul4113012@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > 2. Gcc compiles with /bin/cc, but fails to compile itself, apparently > looping when attempting to compile c-parse.tab.c. The stock cc compiles > this particular file pretty quickly, and I let gcc munch on it for over > eight hours. Has anybody gotten gcc to compile itself? >You must have at least 4 megabytes of memory to run gcc with the >optimizer on. Gcc grows to several megs, and has very poor locality, and >gets paged. Worse, it gets swapped mercilessly because of a mistake in >the ESIX swapper algorithm. Using a system with 4 megs of memory under Interactive, I ran into this same problem with gcc. I recompiled that particular module with cc, and continued to the next stage. The second compiled version of gcc DID compile this module, though it still took over 5 minutes. I put this down to a problem with /bin/cc rather than gcc itself. As an excercise, I later built gcc from scratch (due to some other problems I was having with some code it produced, which /bin/as barfed on), but on the first compile with gcc hit the same problem. This time, I recompiled that module by hand with gcc, ommitting the -O. Worked fine. The second compile also worked without interference. So right now, I don't know what to put it down to. I can concur that it _must_ be memory and the optimiser since during the time it was compiling the machine was running like a dog, which didn't occur with the other modules. david -- _______________________________________________________________________________ Unique Computing Pty Ltd Melbourne Australia - Communications Specialists david@csource.oz.au 3:632/348@fidonet 28:4100/1@signet