HDTenEightyP/NetNews huggingface dataset:
From: rickb@farfle.mti.SGi.COM (Rick Braumoeller)
Subject: Bug in set-window-configuration in Epoch 4.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 09:11:40 GMT

System: SGI Personal Irix running Irix 4.0.5
Epoch version: 4.2.5

I've been using some homegrown Emacs lisp code to keep a group
of window configurations stored that I can toggle through.
This code works fine in vanilla Emacs, but causes Epoch to
crash almost instantly.  Here is the lisp code:

             window-ring.el
---------------------------------------------------
(defun put-at-end (elem list)
  (if (cdr list) (cons (car list) (put-at-end elem (cdr list)))
    (cons (car list) (list elem))))

(defun rotate-ring (ring)
  (cond ((not ring) ())         ; There is no ring to rotate
	((not (cdr ring)) ring) ; Ring has one member
	(t (put-at-end (car ring) (cdr ring)))))
    
(defun prepend-ring (elem ring)
  (cons elem ring))

(defun chop-ring (ring)
  (if (not ring) ()
    (cdr ring)))
    
(defvar window-config-ring ()) ; Start will a null ring

(defun chop-window-config-ring ()
  (interactive)
  (setq window-config-ring
	(chop-ring window-config-ring)))

(defun add-to-window-config-ring ()
  (interactive)
  (setq window-config-ring
	(prepend-ring (current-window-configuration) window-config-ring)))

(defun rotate-window-config-ring ()
  (interactive)
  (setq window-config-ring (rotate-ring window-config-ring))
  (set-window-configuration (car window-config-ring))
  (recenter nil))
  

(global-set-key "\C-c\C-a" 'add-to-window-config-ring)
(global-set-key "\C-t" 'rotate-window-config-ring)
(global-set-key "\C-c\C-q" 'chop-window-config-ring)
------------------------------------------------------

Here's how I cause Epoch to crash.  First, split the
window vertically, then horizontally, and store that
configuration in the window ring (C-x 2 C-x 5 C-c C-a).
Then go back to one window and store that (C-x 0 C-x 0 
C-c C-a).  Now toggle to the previously stored window
config. with C-t.  Epoch has a segmentation fault.

In frustration, I tried (foolishly) to debug this.
I realized soon that this is way beyond my ability, but
here's what little I did find out:

Epoch crashes on line 661-3 on x11term.c, because
ws->cur_char->xpos is an invalid dereference.

661:   if (!ws->cur_line || !ws->cur_char
662:       || ws->cur_char->xpos < w->pixleft
663:       || ws->cur_char->xpos > w->pixleft + w->pixwidth)

ws->cur_char got invalidated on line 526 of x11term.c:

526:   ws->new_cur_char = ws->cur_char = XLINE(w->lines)->body;

w->lines->body is also invalid here (it looks like).

Is it reasonable for me to expect that this will be solved
in the near future?  Or can you guys give me enough to go
on to solve this problem, with a patch, or whatever?
This is really the only thing keeping me from switching
over to Epoch, and I'd REALLY like to switch.

-----
Rick Braumoeller                                 rickb@mti.sgi.com
Silicon Graphics, Inc.                              (415) 390-4506




Newsgroups: gnu.epoch.misc
From: rgb@roadnet.com (Rudy Bonefas)
Subject: Epoch 4.0 and -batch option
Organization: Roadnet Technologies, Inc.
Distribution: gnu.epoch.misc
Date: Thu, 10 Sep 1992 17:27:57 GMT

I can't get the -batch command line switch to work in Epoch 4.0.  Does anyone have a fix for this problem?
From: dglo@manray.Berkeley.EDU (Dave Glowacki)
Newsgroups: gnu.epoch.misc
Subject: Can't get a subshell
Date: 15 Sep 1992 22:02:32 GMT
Organization: University of California, Berkeley
Distribution: gnu
NNTP-Posting-Host: manray.berkeley.edu
Summary: Help the elisp-illiterate!

I've built epoch 4.2 under SunOS 4.1 (both Sun3 and Sun4) and Ultrix 4.1
(DECstation) and have a similar problem with all three binaries.

"M-x shell" and "M-x gdb" both exit with "Process shell exited abnormally
with code 1".

I know that the shell isn't getting started up because I changed my SHELL
variable to point to a little script that logged each usage to a file.
When I did "M-x shell" in an emacs window it worked, but nothing was logged
under epoch.

I'd appreciate any solutions or even pointers toward debugging this problems!
--
Dave Glowacki                 dglo@cs.Berkeley.EDU                   UCBerkeley
-- 
Dave Glowacki                 dglo@cs.Berkeley.EDU                   UCBerkeley
From: bha@bcsaic.boeing.com (Brian Anderson)
Newsgroups: gnu.epoch.misc
Subject: Keymaps in Epoch 4.2
Date: 9 Sep 92 19:05:34 GMT
Distribution: gnu
Organization: Boeing Commercial Airplane, Seattle, Wa.

SunOS 4.1.1
Epoch 4.2
no EIGHTBIT_KEYBOARD defined

Consider the following Elisp code:

(setq *m* (make-keymap)) -> <keymap array>
(length *m*) -> 256 (not 128 as in 4.0.2 or 18.58)
(define-key *m* (char-to-string 127) 'self-insert-command) -> self-insert-command
(define-key *m* (char-to-string 128) 'self-insert-command) -> error
"Key sequence \200 uses invalid prefix characters"

Is this correct behavior?
Am I missing something here or is this a bug?

Thanks.

--
Brian H. Anderson
Boeing Commercial Airplane
(206) 234-0881
bha@atc.boeing.com
From: bardo@ief-paris-sud.fr (Bardo Muller)
Newsgroups: gnu.epoch.misc
Subject: Re: Failure for ascii/temacs to dump
Date: 12 Sep 92 17:54:36 GMT
Reply-To: bardo@ief-paris-sud.fr
Organization: Universite de Paris


In  <9209100629.AA24585@kolmogorov> (Aritomo Shinozaki) writes


	I am running SparcStation-2, SUN OS 4.1.1, SUN C v1.1
	
	everything compiles and dumps fine until we hit the ascii emacs section.
	I did the following:
	1) set config.h for sunOS and sparc
	2) ln -s ../src/config config
	
	but this dumps core during the ascii building phase
	
	../temacs -batch -l inc-vers


Same configuration, same problem. I had already a working epoch version,
so I did 

ln -s /elsewhere/epoch /epoch-dir/src

and the thing compiled fine. But they should locate the bug.

Salut

Bardo
 ___________________________________________________________________________
| Bardo MULLER                          | phone  : [33] [1] 69 41 78 50    |
| Institut d'Electronique Fondamentale  | fax    : [33] [1] 60 19 25 93    |
| Bat. 220 Universite Paris Sud         | e-mail : bardo@ief-paris-sud.fr  |
| 91405 ORSAY CEDEX FRANCE              |             THE NET WORKS !      |
|_______________________________________|__________________________________|
Newsgroups: gnu.epoch.misc
From: david@lama.stanford.edu (Peter R. David)
Subject: Getting windows out from under each other at startup.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 14 Sep 1992 14:06:35 GMT




	To whom it may concern:

	A simple question- How can I prevent the minibuffer window
from being opened on top of the top of my regular window at startup?
This is Epoch version 4.2 compiled with the DEC C compiler under X11R4
with MIT extensions, using motif 1.1.3 window manager on a DECstation
5000/240.  It startups epoch with the origins for both windows in the
same place, obscuring the top two or three lines of the fundamental
buffer.  I can't seem to find the correct value for a resource or
geometery which moves one out from under the other.

	Any hints?

		Thanks,

			Peter David

david@lama.stanford.edu
From: rutt@paradise.mti.sgi.com (John C. Ruttenberg)
Newsgroups: gnu.epoch.misc
Subject: Occasional crash of epoch 4.2 on sgi IRIX 4.05
Date: 9 Sep 92 18:28:15 GMT
Reply-To: rutt@paradise.mti.sgi.com
Organization: Silicon Graphics, Inc.  Mountain View, CA

This happens to me every three or four days.  Most recently I got a core file
for an epoch that was compiled -g.  I took a look at it and I don't think I
can figure out what's going on, but perhaps someone else can.

Here's a stack trace:


kill() ["kill.s":14, 0x4b77f8]
fatal_error_signal(sig=6) ["emacs.c":190, 0x434950]
_sigtramp(<stripped>) ["sigtramp.s":35, 0x4bddf8]
_kill() ["_kill.s":16, 0x4c2588]
raise(<stripped>) ["raise.c":19, 0x4bdd08]
abort(<stripped>) ["abort.c":40, 0x4b5658]
layout_window(window=343875336, just_this_one=0) ["xdispepoch.c":1238, 0x4248a4]
layout_windows(window=343875336) ["xdispepoch.c":1151, 0x4242e4]
layout_window(window=343874824, just_this_one=0) ["xdispepoch.c":1178, 0x424444]
layout_windows(window=343874824) ["xdispepoch.c":1151, 0x4242e4]
redisplay_screen(rb=0x100fe308, force=1) ["xdispepoch.c":1033, 0x423ddc]
redisplay() ["xdispepoch.c":933, 0x423974]
read_command_char(commandflag=1) ["keyboard.c":959, 0x436b74]
read_key_sequence(keybuf="\003\003bh\005\as\214", bufsize=30, prompt=0x0, nodisplay=0) ["keyboard.c":1563, 0x4379ac]
command_loop_1() ["keyboard.c":682, 0x436228]
internal_condition_case(bfun=0x435ff0, handlers=17205520, hfun=0x435a10) ["eval.c":1018, 0x4689d8]
command_loop_2() ["keyboard.c":553, 0x435e00]
internal_catch(tag=17205500, func=0x435de4, arg=17205260) ["eval.c":826, 0x468310]
command_loop() ["keyboard.c":535, 0x435da0]
recursive_edit_1() ["keyboard.c":420, 0x435948]
Frecursive_edit() ["keyboard.c":402, 0x4358bc]
main(argc=1, argv=0x7fffc774, envp=0x7fffc77c) ["emacs.c":565, 0x435080]
__start(<stripped>) ["crt1text.s":99, 0x400238]

I could probably get the core and executable file to anyone who cared.
From: elges@daneel.den.mmc.com (Mike Elges)
Newsgroups: gnu.epoch.misc
Subject: Epoch and X11R5
Date: 15 Sep 92 14:40:52 GMT
Distribution: gnu
Organization: GNUs Not Usenet

Hello all

My Platform

486 Machine Running ISC SYS V R 3 Version 3.0
(this is now shipped as a sun soft product)

Have compiled X11 R5 from MIT with patch level 16 applied also with the
X386 1.2E 1.0.2 update applied.

I can compile epoch 4.2 just fine using s-isc2-2.h and m-intel386.h set in the
config file and no other changes in the config file.  The problem is that when
I try to invoke epoch I get an xlib warning that the client is built for 
an earlier version of the server.  It say:

xlib warning: client built for version (0) and server is version (16342)

Then it just sits there and does not give me any epoch windows 
(i.e mini-buffer).  I have no Idea what to try next.  I hav search the FAQ
but found nothing to fix this.  I did find that I get the same error when
I try to run EMACS that was compiled using HAVE_X11 defined so at least it is
consistant.

Any Ideas or help would be greatly appreciated.

Thanks in Advance

-- 
Michael Elges
elges@daneel.den.mmc.com
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Newsgroups: gnu.epoch.misc
Subject: Patch for Epoch 4.2
Date: 11 Sep 92 10:24:40 GMT
Distribution: gnu
Organization: GNUs Not Usenet

Here's a patch for src/keymap.c to fix a problem M-<key>
representation when not using the EIGHTBIT_KEYBOARD option:

--------------------------------- CLIP HERE ----------------------------------
*** keymap.c.orig	Fri Sep 11 17:04:24 1992
--- keymap.c	Fri Sep 11 17:10:43 1992
***************
*** 640,655 ****
       register unsigned int c;
       register char *p;
  {
-   if (c < 040)
-     {
  #ifndef EIGHTBIT_KEYBOARD
!       if (c >= 0200)
!         {
!           *p++ = 'M';
!           *p++ = '-';
!           c -= 0200;
!         }
  #endif /* not EIGHTBIT_KEYBOARD */
        if (c == 033)
  	{
  	  *p++ = 'E';
--- 640,655 ----
       register unsigned int c;
       register char *p;
  {
  #ifndef EIGHTBIT_KEYBOARD
!   if (c >= 0200)
!     {
!       *p++ = 'M';
!       *p++ = '-';
!       c -= 0200;
!     }
  #endif /* not EIGHTBIT_KEYBOARD */
+   if (c < 040)
+     {
        if (c == 033)
  	{
  	  *p++ = 'E';
--------------------------------- CLIP HERE ----------------------------------

(This fixes the problem with, e.g., binding 'help-command to \M-h,
then pressing M-h and getting a funky eightbit-character in the echo
area instead of the M-h- prompt.)

Marc

--
Marc Andreessen
Epoch Development Team
University of Illinois at Urbana-Champaign
marca@ncsa.uiuc.edu
Newsgroups: gnu.epoch.misc
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: Failure for ascii/temacs to dump
Organization: Nat'l Center for Supercomputing Applications
Date: Sun, 13 Sep 1992 01:08:47 GMT

In article <1992Sep12.180338.16380@greco-prog.fr> bardo@ief-paris-sud.fr (Bardo Muller) writes:

   In  <9209100629.AA24585@kolmogorov> (Aritomo Shinozaki) writes

           I am running SparcStation-2, SUN OS 4.1.1, SUN C v1.1

           everything compiles and dumps fine until we hit the ascii emacs section.
           I did the following:
           1) set config.h for sunOS and sparc
           2) ln -s ../src/config config

           but this dumps core during the ascii building phase

           ../temacs -batch -l inc-vers

   Same configuration, same problem. I had already a working epoch version,
   so I did 

   ln -s /elsewhere/epoch /epoch-dir/src/temacs          (hopefully...)
                                     ##############
   and the thing compiled fine. But they should locate the bug.

OK, folks, Epoch 4.2 compiles out of the box, without changes (except
for ascii/config.h), on my Sparcstations (three different ones), with
stock cc:

[marca_ttyp0@ash /home/kaplan/marca] uname -a
SunOS ash.cs.ui 4.1.2 2 sun4c

(marca@void 75) uname -a
SunOS void 4.1.2 1 sun4m

(marca@zaphod 89) uname -a
SunOS zaphod 4.1.1 1 sun4c

So, those of you having problems building on this platform should (1)
tell me exactly what you did after untarring the Epoch distribution
and (2) also send me a copy of the appropriate config files; (3) also,
dbx any coredumps and send me the traceback.

Thanks,

Marc


--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu
Newsgroups: gnu.epoch.misc
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Patch for Epoch 4.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 13 Sep 1992 09:43:10 GMT

  /k.b./ I haven't been bitten by this problem.  Should I bother
  /k.b./ installing the patch, or will it be incorporated into an
  /k.b./ upcoming epoch release?

It will be in 4.3, which may not be along for a while.  If the problem
hasn't bit you, then don't worry about it....

Marc

--
Marc Andreessen
Epoch Development Team
University of Illinois at Urbana-Champaign
marca@ncsa.uiuc.edu
From: bardo@ief-paris-sud.fr (Bardo Muller)
Newsgroups: gnu.epoch.misc
Subject: Re: Failure for ascii/temacs to dump
Date: 12 Sep 92 18:03:38 GMT
Reply-To: bardo@ief-paris-sud.fr
Organization: Universite de Paris

Newsgroups: gnu.epoch.misc
Path:geocub!gonzales!bardo
From bardo@ief-paris-sud.fr (Bardo Muller)
Subject: Re: Failure for ascii/temacs to dump
Reply-To: bardo@ief-paris-sud.fr
Organization: Universite de Paris
Date: Sat, 12 Sep 1992 17:54:36 GMT


In  <9209100629.AA24585@kolmogorov> (Aritomo Shinozaki) writes


	I am running SparcStation-2, SUN OS 4.1.1, SUN C v1.1
	
	everything compiles and dumps fine until we hit the ascii emacs section.
	I did the following:
	1) set config.h for sunOS and sparc
	2) ln -s ../src/config config
	
	but this dumps core during the ascii building phase
	
	../temacs -batch -l inc-vers


Same configuration, same problem. I had already a working epoch version,
so I did 

ln -s /elsewhere/epoch /epoch-dir/src/temacs          (hopefully...)
                                  ##############
and the thing compiled fine. But they should locate the bug.

Salut

Bardo
 ___________________________________________________________________________
| Bardo MULLER                          | phone  : [33] [1] 69 41 78 50    |
| Institut d'Electronique Fondamentale  | fax    : [33] [1] 60 19 25 93    |
| Bat. 220 Universite Paris Sud         | e-mail : bardo@ief-paris-sud.fr  |
| 91405 ORSAY CEDEX FRANCE              |             THE NET WORKS !      |
|_______________________________________|__________________________________|
From: jmay@ctp.com (Jason May)
Newsgroups: gnu.epoch.misc
Subject: Cursor stuck in minibuffer?
Date: 14 Sep 92 17:23:13 GMT
Article-I.D.: ctp.1992Sep14.172313.23493
Organization: Cambridge Technology Partners


An odd problem has been cropping up occasionally, but I have not
been able to reproduce it on demand.  From time to time, the cursor
will get stuck in the minibuffer, when no minibuffer command is active.
I can select another buffer by clicking on it, but whenever I activate
another window (eg. by moving the mouse; I use keyboardFocusPolicy: pointer),
the cursor goes back into the minibuffer.  I use 'epoch -nm' to put
the minibuffer at the bottom of each epoch window.  The only way I've
found to fix things when this happens is to exit epoch completely and
start it up again.

If I try typing anything in the minibuffer and pressing return, I get
the message "No catch for tag: exit, nil".

Is there some way to get epoch to reset itself, sort of the equivalent
of 'stty sane'?  Any help is appreciated.

Thanks,
Jason

-- 
======================================================================
Jason W. May	jmay@ctp.com
CTP, Inc.   304 Vassar St.   Cambridge MA 02139   (617)374-8223
======================================================================
Newsgroups: gnu.epoch.misc
Subject: Re: epoch 4.2 build problem - `__builtin_saveregs'?
From: phys229@cantua.canterbury.ac.nz (Mr. A.D. McGregor)
Date: 14 Sep 92 09:15:54 +1200
Distribution: world
Organization: University of Canterbury, Christchurch, New Zealand.

In article <82589@bcsaic.boeing.com>, chrise@atc.boeing.com (Chris_Esposito) writes:
> I have a problem in building epoch 4.2 on a Sparc2, OS 4.1.2, with
> gcc -O -g -traditional.  Everything (jncluding xpm support) compiles
> fine until the final attempt to link everything into temacs, and then ...
> 
> ld  -e __start -Bstatic -L/usr/openwin/lib -L/usr/local/lib -o temacs crt0.o
 window.o  term.o x11term.o x11fns.o xevent.o screen.o xdefault.o xresource.o
 property.o selection.o xutil.o mouse.o button.o xdispepoch.o dispepoch.o
  emacs.o keyboard.o macros.o>  keymap.o sysdep.o  buffer.o filelock.o insdel.o
 marker.o  minibuf.o fileio.o dired.o filemode.o  cmds.o casefiddle.o indent.o
 search.o regex.o undo.o  alloc.o data.o doc.o editfns.o callint.o  eval.o fns.o
 print.o lread.o  abbrev.o syntax.o unexec.o mock> lisp.o bytecode.o  process.o
 callproc.o environ.o  doprnt.o lastfile.o malloc.o  -lX11 -lXpm   -lg  -lc
> Undefined
> ___builtin_saveregs <-- **DOES anyone know what this is, or where to get it?
> *** Error code 2
> make: Fatal error: Command failed for target `temacs'
> Current working directory /a/grace/local/share.sunos.4.1.2/src/epoch4.2/src
> *** Error code 1
> make: Fatal error: Command failed for target `doall'
> Exit 1
> 
> Thanks,
> Chris

Someone else postard with a similar problem. Mine built OK with gcc 2.2.2
once I fiddled with the switches in ld:

ld -e __start -Bstatic -L/usr/local/X11/lib -o <lots of objects>
-lX11 -lg -L/usr/local/phys/lib/gcc-lib/sun4/2.2.2 -lgcc -lc

given that the gcc libraries are pointed to by that path.
You must have -lgcc BEFORE -lc with this compiler.
By the way, does anybody know why I had to point ld at that directory?
the docs for gcc say that one shouldn't have to.

Hope this helps,
Andrew McGregor
Physics, University of Canterbury, Christchurch, New Zealand.

Newsgroups: gnu.epoch.misc
From: peterf@zuben.csis.dit.csiro.au (Peter A Fletcher)
Subject: scroll-down and scroll-up don't work with mixed fonts
Organization: CSIRO Division of Information Technology
Date: Wed, 9 Sep 1992 02:41:28 GMT

Hi!

    I'm using epoch-4.2, and it scroll-down and scroll-up do not work
with mixed height fonts; epoch seems to scroll too many lines.  I have
defined some functions:

(defun scroll-up-half ()
  "Scroll up half a windowfull"
  (interactive)
  (scroll-up (/ (window-height) 2))
)

(defun scroll-down-half ()
  "Scroll down half a windowfull"
  (interactive)
  (scroll-down (/ (window-height) 2))
)

which work even worse.

-peter
--
Peter Fletcher,            Internet : peterf@csis.dit.csiro.au
PhD Student                Physical : CSIRO Division of Information Technology,
Phone    : +61-6-2750914              ANU, Acton, Canberra ACT AUSTRALIA
-------------------------------------------------------------------------------
From: tdunbar@vttcf.cc.vt.edu (Thomas Dunbar)
Newsgroups: gnu.epoch.misc
Subject: TeX viewer package for Epoch- where ?
Date: 6 Sep 92 12:43:43 GMT
Organization: Virginia Tech, Blacksburg, VA


 there is a package for epoch (and lucid) that enables one to see/use
TeX special characters inside epoch..i've lost the archive and the 
address, which is in France i believe.. author ? R Marlet ? 
  the package is called viewer..can someone email me the ftp site?
   thanks,
    thomas
     (tdunbar@vttcf.cc.vt.edu)
Newsgroups: gnu.epoch.misc
From: klash@bnr.ca (Karl (K.B.) Klashinsky)
Subject: Re: Patch for Epoch 4.2
Organization: Bell-Northern Research, Ltd.
Distribution: gnu
Date: Sun, 13 Sep 1992 07:18:28 GMT

I haven't been bitten by this problem.  Should I bother
installing the patch, or will it be incorporated into an
upcoming epoch release?


-- 
klash
                                                                     2
                        To be, or not to be -- that is the root of 4b.
Newsgroups: gnu.epoch.misc
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: oui
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 14 Sep 1992 09:13:50 GMT

Thanks for all the translations... :-)

Marc

--
Marc Andreessen
Epoch Development Team
University of Illinois at Urbana-Champaign
marca@ncsa.uiuc.edu

Newsgroups: gnu.epoch.misc
From: gwolsk@seidc.UUCP (Guntram Wolski)
Subject: epoch under MIPS RISCos 4.52/5.0
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 8 Sep 1992 18:14:14 GMT


I have tried compiling epoch-4.2 that I obtained Monday evening from
cs.uiuc.edu on a MIPS R3330 running RISCos 4.52 and another one
running the "new" RISCos 5.0.  I am using the system default compilers
in the bsd43 world (i.e. /bsd43/bin/cc). I am running with
config/s-bsd4-3.h and m-mips4.h.

The following two comments apply to both OSs and the last at the
bottom only to RISCos 5.0.  Once I implemented item 2, I was able to
get a version of epoch for RISCos 4.52.  The third item is preventing
me from doing it under 5.0.

1)	The KERNEL_FILE is defined as "/vmunix" in the s-bsd4-3.h
which shouldn't work for mips.  I added a define in m-mips4.h to
change it to /unix.  Maybe I missing something.

2)	I had to modify src/fileio.c for BOTH systems so that the NULL
definition in lisp.h was defined AFTER the inclusion of <sys/dir.h>
where it is defined again!

*** src/fileio.c.fcs	Tue Sep  8 09:33:09 1992
--- src/fileio.c	Tue Sep  8 09:40:50 1992
***************
*** 71,79 ****
  #undef NULL
  #endif
  #include "config.h"
- #include "lisp.h"
- #include "buffer.h"
- #include "window.h"
  
  #ifdef SYSV_SYSTEM_DIR
  #include <dirent.h>
--- 71,76 ----
***************
*** 80,85 ****
--- 77,89 ----
  #else
  #include <sys/dir.h>
  #endif
+ 
+ #ifdef NULL
+ #undef NULL
+ #endif
+ #include "lisp.h"
+ #include "buffer.h"
+ #include "window.h"
  
  #ifdef VMS
  #include <file.h>


3)	I am having difficulty having it "kill" itself under RISCos
5.0 (it dumped fine under 4.52).  It doesn't seem to want to generate
an 'epoch' when it says it is dumping:

Dumping under names epoch and epoch-4.2.7
make[1]: *** [epoch] Killed
make: *** [doall] Error 1


I don't understand enough to figure this out yet.  RISCos 5.0 has
dynamic libs and is more SVR4 like.  Any tips on why it won't dump
itself you give me are appreciated.

Thanks,
--G
--
Guntram Wolski                   gwolsk@sei.com
Silicon Engineering, Inc.        408-438-5331 x112
...!{sgiblab,ames}!seidc!gwolsk

Newsgroups: gnu.bash.bug