flag or otherwise (see cc(1)).  This may work on earlier Irix 6  systems if you edit src/s/irix6-0.h following irix6-5.h.  If compiling with GCC on Irix 6 yields an error "conflicting types  for `initstate'", install GCC 2.95 or a newer version, and this  problem should go away.  It is possible that this problem results  from upgrading the operating system without reinstalling GCC; so you  could also try reinstalling the same version of GCC, and telling us  whether that fixes the problem.  Building Emacs 21.1 and 21.2 on versions of Irix before 6.5.10,  especially when Emacs is built with GCC, was reported to have subtle  problems such as being unable to print to stdout under the -batch  command-line option.  Building with the native compiler or upgrading  the OS to a newer version solves these problems.  There's evidence  that these problems are actually related to the runtime libraries  (before IRIX 6.5.10, the IRIX runtimes were based on the MIPSpro 7.2  compilers), so installing patches for the runtime from  http://www.sgi.com/support/patch_intro.html could solve the problem  even without upgrading the OS.  The dump process is the crucial  step that needs the upgraded runtime, so a workaround is to dump  Emacs on a machine with a newer OS, then copy the binary to the  older OS.  The 19.26 pretest was reported to work on IRIX 4.0.5 and 5.2.  19.23 was reported to work on IRIX 5.2, but you may need to install  the "compiler_dev.hdr.internal" subsystem in order to compile unexelfsgi.c.  19.22 was known to work on all Silicon Graphics machines running  IRIX 4.0.5 or IRIX 5.1.  Compiling with -O using IRIX compilers prior to 3.10.1 may not work.  Don't use -O or use GCC instead.  Most IRIX 3.3 systems do not have an ANSI C compiler, but a few do.  Compile Emacs 18 with the -cckr switch on these machines.  There is a bug in IRIX 3.3 that can sometimes leave ptys owned by root  with a permission of 622.  This causes malfunctions in use of  subprocesses of Emacs.  Irix versions 4.0 and later with GNU Emacs  versions 18.59 and later fix this bug.Masscomp (m68k-masscomp-rtu)  18.36 worked on a 5500DP running RTU v3.1a and compiler version 3.2  with minor fixes that are included in 18.37.  However, bizarre behavior  was reported for 18.36 on a Masscomp (model and version unknown but probably  a 68020 system).  The report sounds like a compiler bug.  A compiler bug affecting statements like     unsigned char k; unsigned char *p;... x = p[k];  has been reported for "C version 1.2 under RTU 3.1".  We do not wish  to take the time to install the numerous workarounds required to  compensate for this bug.  For RTU version 3.1, define FIRST_PTY_LETTER to be 'p' in `src/s/rtu.h'  (or #undef and redefine it in config.h) so that ptys will be used.  GNU Emacs is said to have no chance of compiling on RTU versions  prior to v3.0.Megatest (m68k-megatest-bsd)  Emacs 15 worked; do not have any reports about Emacs 16 or 17  but any new bugs are probably not difficult.Mips (mips-mips-riscos, mips-mips-riscos4.0, or mips-mips-bsd)  The C compiler on Riscos 4.51 dumps core trying to optimize  parts of Emacs.  Try without optimization or try GCC.  Meanwhile, the linker on that system returns success even if  there are undefined symbols; as a result, configure gets the  wrong answers to various questions.  No work-around is known  except to edit src/config.h by hand to indicate which functions  don't exist.  Use mips-mips-riscos4.0 for RISCOS version 4.  Use mips-mips-bsd with the BSD world.  Note that the proper configuration names for DECstations are  mips-dec-ultrix and mips-dec-osf.  If you are compiling with GCC, then you must run fixincludes;  the alternative of using -traditional won't work because  the definition of SIGN_EXTEND_CHAR uses the keyword `signed'.  If the SYSV world is the default, then you probably need the following  line in etc/Makefile:    CFLAGS= -g -systype bsd43  Some operating systems on MIPS machines give SIGTRAP for division by  zero instead of the usual signals.  The only real solution is to fix  the system to give a proper signal.  In the meantime, you can change init_data in data.c if you wish.  Change it to handle SIGTRAP as well as SIGFPE.  But this will have a  great disadvantage: you will not be able to run Emacs under a  debugger.  I think crashing on division by zero is a lesser problem.  dsg@mitre.org reported needing to use --x-libraries=/bsd43/usr/lib  on a riscos4bsd site.  But it is not clear whether this is needed in  general or only because of quirks on a particular site.National Semiconductor 32000 (ns32k-ns-genix)  This is for a complete machine from National Semiconductor,  running Genix.  Changes merged in version 19.NCR Tower 32 (m68k-ncr-sysv2 or m68k-ncr-sysv3)  If you are running System V release 2, use m68k-ncr-sysv2.  If you are running System V release 3, use m68k-ncr-sysv3.  These both worked as of 18.56.  If you change `src/ymakefile' so that  CFLAGS includes C_OPTIMIZE_SWITCH rather than C_DEBUG_SWITCH, check  out the comments in `src/m/tower32.h' (for System V release 2) or  `src/m/tower32v3.h' (for System V release 3) about this.  There is a report that compilation with -O did not work with 18.54  under System V release 2.NCR Intel system (i386-ncr-sysv4.2)  This system works in 19.31, but if you don't link it with GNU ld,  you may need to set LD_RUN_PATH at link time to specify where  to find the X libraries.NEC EWS4800 (mips-nec-sysv4)  This system works in 20.4, but you should use the compiler  /usr/abiccs/bin/cc (MIPS ABI MODE).NeXT (m68k-next-nextstep)  Emacs 19 has not been tested extensively yet, but it seems to work  in a NeXTStep 3.0 terminal window, and under the X server called  co-Xist.  You may need to specify -traditional when src/Makefile  builds xmakefile.  NeXT users might want to implement direct operation with NeXTStep,  but from the point of view of the GNU project, that is a  distraction.  Thanks to Thorsten Ohl for working on the NeXT port of Emacs 19.Nixdorf Targon 31 (m68k-nixdorf-sysv)  Machine description file for version 17 is included in 18  but whether it works is not known.  `src/unexec.c' bombs if compiled with -O.  Note that the "Targon 35" is really a Pyramid.Nu (TI or LMI) (m68k-nu-sysv)  Version 18 is believed to work.Paragon OSF/1 (i860-intel-osf1)  Changes merged in 19.29.  There is a bug in OSF/1 make which claims there is a syntax error  in the src/xmakefile.  You can successfully build emacs with:        pmake MAKE=pmakePlexus (m68k-plexus-sysv)  Worked as of 17.56.Pmax (DEC Mips)  (mips-dec-ultrix or mips-dec-osf1)  See under DECstation, above.Prime EXL (i386-prime-sysv)  Minor changes merged in 19.1.Pyramid (pyramid-pyramid-bsd)  The 19.26 pretest was observed to work on OSx 5.0, but it is necessary  to edit gmalloc.c.  You must add #include <sys/types.h> at the top,  and delete the #define for size_t.  You need to build Emacs in the Berkeley universe with  the `ucb' command, as in `ucb make' or `ucb build-install'.    In OSx 4.0, it seems necessary to add the following two lines  to `src/m/pyramid.h':     #define _longjmp longjmp     #define _setjmp setjmp  In Pyramid system 2.5 there has been a compiler bug making  Emacs crash just after screen-splitting with Qnil containing 0.  A compiler that fixes this is Pyramid customer number 8494,  internal number 1923.  Some versions of the pyramid compiler get fatal  errors when the -gx compiler switch is used; if this  happens to you, change `src/m/pyramid.h' to define  C_DEBUG_SWITCH with an empty definition.  Some old system versions may require you to define PYRAMID_OLD  in when alloca.s is preprocessed, in order to define _longjmp and _setjmp.Sequent Balance (ns32k-sequent-bsd4.2 or ns32k-sequent-bsd4.3)  Emacs 18.51 worked on system version 3.0.  18.52 is said to work.  Delete some lines at the end of `src/m/sequent.h' for earlier system  versions.Sequent Symmetry (i386-sequent-bsd, i386-sequent-ptx, i386-sequent-ptx4)  19.33 has changes to support ptx 4 (a modified SVR4).  Emacs 19 should work on Dynix (BSD).  However, if you compile with  the Sequent compiler, you may find Emacs does not restore the  terminal settings on exit.  If this happens, compile with GCC.  Emacs 19.27 contains patches that should support  DYNIX/ptx 1.4 and 2.1 with the native cc compiler.  GCC can't compile src/process.c due to a non-standard Sequent asm  keyword extension supported by cc and used for the network byte/word  swapping functions in the PTX /usr/include/netinet/in.h file.  GCC  2.5.8 includes the file <sys/byteorder.h> which can be included into  netinet/in.h to perform these byte/word swapping functions in the  same manner.  Patches have been submitted to the FSF against GCC  2.6.0 to fix this problem and allow Emacs to be built with GCC.  If your machine does not have TCP/IP installed, you will have to edit the  src/s/ptx.h file and comment out #define TCPIP_INSTALLED.Siemens Nixdorf RM600 and RM400 (mips-siemens-sysv4)  Changes merged in 19.29.  This configuration should also work for  Pyramid MIS Server running DC-OSX 1.x.  The version configured with  `--with-x' works without any modifications, but `--with-x-toolkit'  works only if the Athena library and the Toolkit library are linked  statically.  For this, edit `src/Makefile' after the `configure' run  and modify the lines with `-lXaw' and `-lXt' as follows:    LIBW= /usr/lib/libXaw.a    LIBXT= $(LIBW) -lXmu /usr/lib/libXt.a $(LIBXTR6) -lXext  In addition, `--with-x-toolkit=motif' works only  if the Motif library and the Toolkit library are linked statically.  To do this, edit `src/Makefile' after the `configure' run  and modify the lines with `-lXm' and `-lXt' as follows:    LIBW= /usr/lib/libXm.a /usr/ccs/lib/libgen.a    LIBXT= $(LIBW) -lXmu /usr/lib/libXt.a $(LIBXTR6) -lXextSONY News (m68k-sony-bsd4.2 or m68k-sony-bsd4.3)  18.52 worked.  Use m68k-sony-bsd4.3 for system release 3.SONY News 3000 series (RISC NEWS) (mips-sony-bsd)  The 19.26 pretest is reported to work.  Some versions of the operating system give SIGTRAP for division by zero  instead of the usual signals.  This causes division by zero  to make Emacs crash.  The system should be fixed to give the proper signal.  Changing Emacs is not a proper solution, because it would prevent  Emacs from working under any debugger.  But you can change init_data  in data.c if you wish.Stardent i860 (i860-stardent-sysv4.0)  19.26 pretest reported to work.Stardent 1500 or 3000  See Titan.Stride (m68k-stride-sysv)  Works (most recent news for 18.30) on their release 2.0.  For release 2.2, see the end of `src/m/stride.h'.  It may be possible to run on their V.1 system but changes  in the s- file would be needed.Sun 3, Sun 4 (sparc), Sun 386 (m68k-sun-sunos, sparc-sun-sunos, i386-sun-sunos,			       sparc-sun-sunos4.1.3noshr, sparc-sun-solaris2.*,			       i386-sun-solaris2.*, sparc*-*-linux-gnu)  To build a 64-bit Emacs (with larger maximum buffer size and  including large file support) on a Solaris system which supports  64-bit executables, use the Sun compiler, configuring something like  this (see the cc documentation for information on 64-bit  compilation):  env CC="cc -xarch=v9" ./configure  As of version 2.95, GCC doesn't support the 64-bit ABI properly, but  later releases may.  Some versions of Solaris 8 have a bug in their XIM (X Input Method)  implementation which causes Emacs to dump core when one of several  frames is closed.  To avoid this, either install patch 108773-12  (for Sparc) or 108874-12 (for x86), or configure Emacs with the  `--with-xim=no' switch (you can use Leim input methods instead).  On Solaris 2.7, building Emacs with WorkShop Compilers 5.0 98/12/15  C 5.0 failed, apparently with non-default CFLAGS, most probably due to  compiler bugs.  Using Sun Solaris 2.7 Sun WorkShop 6 update 1 C  release was reported to work without problems.  It worked OK on  another system with Solaris 8 using apparently the same 5.0 compiler  and the default CFLAGS.  Emacs 21.1 and 21.2 built with Sun's ProWorks PC3.0.1 compiler on  Intel/Solaris 8 was reported to abort and dump core during startup.  Using GCC or a newer SUN compiler (Sun WokShop 6 update 2 C 5.3  2001/05/15) solves the problem.  Emacs 20.5 and later work on SPARC GNU/Linux with the 32-bit ABI.  As of release 2.95, GCC doesn't work properly with the 64-bit ABI  (applicable on UltraSPARC), but that isn't the default mode.  Emacs 20.3 fails to build on Solaris 2.5 if you use GCC 2.7.2.3.  Installing GCC 2.8 fixes the problem.  19.32 works on Solaris 2.4 and 2.5.  On Solaris 2.5  you may need one of these patches to prevent Emacs from crashing  when it starts up:        103093-03: [README] SunOS 5.5: kernel patch (2140557 bytes)         102832-01: [README] OpenWindows 3.5: Xview Jumbo Patch (4181613 bytes) 	103242-04: [README] SunOS 5.5: linker patch (595363 bytes)  There are reports that using SunSoft cc with -xO4 -xdepend produces  bad code for some part of Emacs.  Emacs works ok Sunos 4.1.x  provided you completely replace your C shared library  using one of the SunOS 4.1.x jumbo replacement patches from Sun.  Here are the patch numbers for Sunos 4.1.3:   100890-10   SunOS 4.1.3: domestic libc jumbo patch   100891-10   SunOS 4.1.3: international libc jumbo patch  Some people report that Emacs crashes immediately on startup when  used with a non-X terminal, but we think this is due to compiling  with GCC and failing to use GCC's "fixed" system header files.  Some Sun versions of X windows use the clipboard, not the selections,  for transferring text between clients.  The Cut, Paste and Copy items  in the menu bar Edit menu work with the clipboard.  It's important to include the SunOS version number in the  configuration name.  For example, for SunOS release 4.0 on a Sun 3,  use `m68k-sun-sunos4.0'; for SunOS release 4.1 on a Sparc, use  `sparc-sun-sunos4.1'.  For SunOS release 4.1.3 on a Sparc, use  `sparc-sun-sunos4.1.3'.  Note that shared libraries are now  used by default on SunOS 4.1.    A user reported irreproducible segmentation faults when using 19.29  on Solaris 2.3 and 2.4 after compiling it with the Sun compiler.  The problem went away when GCC 2.7.0 was used instead.  We do not know  whether anything in Emacs is partly to blame for this.  X11R6 is set up to make shared libraries only, on Sunos 4.  Therefore, in order to link Emacs, you need to create static X libraries.  To do this, rebuild X11 after setting    #define ForceNormalLib YES    #define SeparateSharedCompile YES  in site.def (after #ifdef AfterVendorCF).  Use `m68k' for the 68000-based Sun boxes, `sparc' for Sparcstations,  and `i386' for Sun Roadrunners.  i386 calls for Sunos4.0.  If you compile with Sun's ANSI compiler acc, you need additional options  when linking temacs, such as     /usr/lang/SC2.0.1/values-Xt.o -L/usr/lang/SC2.0.1/cg87 -L/usr/lang/SC2.0.1  (those should be added just before the libraries) and you need to