machines

windows版本的emacs

  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.

  [e-mail] 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=pmake

Plexus (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) -lXext

SONY 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