-This is a list of the status of GNU Emacs on various machines and systems.
+This is a list of the status of XEmacs on various machines and systems.
+See PROBLEMS for particular problems and possible workarounds.
-For each system and machine, we give the configuration name you should
-pass to the `configure' script to prepare to build Emacs for that
-system/machine.
+Much effort has gone into making XEmacs work on as many different
+machines, configurations, and compilers as possible.
-The `configure' script uses the configuration name to decide which
-machine and operating system description files `src/config.h' should
-include. The machine description files are all in `src/m', and have
-names similar to, but not identical to, the machine names used in
-configuration names. The operating system files are all in `src/s',
-and are named similarly. See the `configure' script if you need to
-know which configuration names use which machine and operating system
-description files.
+Much effort has gone into making XEmacs 64-bit clean.
-If you add support for a new configuration, add a section to this
-file, and then edit the `configure' script to tell it which
-configuration name(s) should select your new machine description and
-system description files.
+Much effort has gone into removing system-specific code, and replacing
+such code with autodetection at configure time.
-\f
-Here are the configurations Emacs is intended to work with, with the
-corresponding configuration names. You can postpend version numbers
-to operating system names (i.e. sunos4.1) or architecture names (i.e.
-hppa1.1). If you leave out the version number, the `configure' script
-will configure Emacs for the latest version it knows about.
+The XEmacs core should build "out of the box" on most Unix-like systems.
-*************************************************************************
-* *
-* NOTE: this file is kept in sync with the FSF version, though we *
-* expect the information here to be mostly accurate for XEmacs. *
-* Bear in mind that the version numbers mentioned in the text below *
-* are the FSF numbers, not the Lucid numbers. For comparison, *
-* FSFmacs 19.26 roughly corresponds to XEmacs 19.11. *
-* *
-*************************************************************************
+XEmacs 21.2 was tested and `make check' succeeded on these Unix
+configurations as of 2001-02-10:
-Acorn RISCiX (arm-acorn-riscix1.2)
+alphaev56-dec-osf4.0e (both Compaq C and gcc)
+i386-unknown-freebsd4.2
+i386-unknown-netbsdelf1.5
+i586-sco-sysv5uw7.0.1 (both SCO's cc and gcc)
+i686-pc-linux-gnu
+hppa2.0-hp-hpux10.20 (both HP's ANSI cc and gcc)
+mips-sgi-irix6.5 (both MIPSpro cc and gcc)
+rs6000-ibm-aix4.3.0.0 (both IBM's xlc and gcc)
+sparc-sun-solaris2.6 (both Sun's Forte C and gcc)
+sparc-sun-solaris2.7 (both Sun's Forte C and gcc)
+sparc-sun-sunos4.1.4 (gcc)
- Emacs 19.29 has changes that ought to support RISCiX 1.2.
+Some systems have a dual mode 32-bit/64-bit compiler. On most of
+these, XEmacs requires the --pdump configure option to build
+correctly with the 64-bit version of the compiler.
- Due to a bug in the RISCiX C compiler (3.4.5), emacs must
- be built with gcc (versions 2.5.8 onwards).
+mips-sgi-irix6.5, CC="gcc -mabi=64"
+mips-sgi-irix6.5, CC="cc -64"
+rs6000-ibm-aix4.3.0.0, CC="cc -q64"
- In addition, you will need GNU sed and GNU make, as the RISCiX release
- versions of these utilities cannot cope with building emacs-19!
+On most of these systems, XEmacs also builds with a C++ compiler,
+but not "out of the box". This feature is only for use by the
+maintainers.
- GNU sed should be configured with:
+XEmacs 21.2 is known _not_ to work on any machines with m680x0
+processors. Sorry, all you sun3 and Unix PC nostalgia buffs out there.
- env 'DEFS=-Dgetopt=gnu_getopt -Dopterr=gnu_opterr -Doptind=gnu_optind \
- -Doptarg=gnu_optarg' ./configure
-
- GNU make (3.72+) should be configured with:
-
- env 'CFLAGS=-Dgetopt=gnu_getopt -Dopterr=gnu_opterr -Doptind=gnu_optind \
- -Doptarg=gnu_optarg' ./configure
-
- Emacs may be configured to use the X toolkit, by adding --with-x-toolkit
- to the configure command. If you do this, you will need to edit the line
- in src/Makefile which defines LIBW (about line 59) to read:
-
- LIBW= -lXaw_n
-
- This ensures that the non-shared widget library is used.
-
- It is unlikely that this version of emacs will work with RISCiX 1.1.
-
-Alliant (fx80-alliant-bsd):
-
- 18.52 worked on system version 4. Previous Emacs versions were
- known to work on previous system versions.
-
- If you are using older versions of their operating system, you may
- need to edit `src/config.h' to use `m/alliant1.h' (on version 1) or
- `m/alliant.h' (on versions 2 and 3).
-
-Alliant FX/2800 (i860-alliant-bsd)
-
- Known to work with 19.26 and OS version 2.2, compiler version 1.3.
-
-Alpha (DEC) running OSF/1 (alpha-dec-osf1)
-
- Worked as of Lucid Emacs 19.8.
-
-Altos 3068 (m68k-altos-sysv)
-
- 18.52 was said to work, provided you don't compile unexec.c with -O.
-
-Amdahl UTS (580-amdahl-sysv)
-
- Small changes for 18.38 were merged in 18.39. It is mostly
- working, but at last report a bug sometimes causes Emacs to
- grab very large amounts of memory. No fix or explanation
- has yet been reported. It may be possible to find this bug
- if you find which Emacs command it happens within and then
- run that command with a breakpoint set at malloc.
-
- The 5.2u370 compiler is so brain damaged that it is not
- even worth trying to use it. Success was obtained with the
- uts native C compiler on uts version 5.2.5.
-
-Apollo running Domain (m68k-apollo-domain)
-
- 19.29 has a few patches that ought to make things work.
-
- There are reports of bugs in cc -O on this system.
-
- In `lib-src/Makefile', don't expect emacsclient and emacsserver to
- compile. You might want to remove them from your makefile.
-
- The Apollo has a bizarre operating system which does not permit
- Emacs to be dumped with preloaded pure Lisp code. Therefore, each
- time you start Emacs on this system, the standard Lisp code is loaded
- into it. Expect it to take a long time. You can prevent loading of
- the standard Lisp code by specifying the -nl switch. It must
- come at the beginning of the command line; only the -t and -batch
- switches may come before it.
-
-
- Here is a design for a method of dumping and reloading the relevant
- necessary impure areas of Emacs.
-
- On dumping, you need to dump only the array `pure' plus the
- locations that contain values of forwarded Lisp variables or that are
- protected for garbage collection. The former can be found by a
- garbage- collection-like technique, and the latter are in the
- staticprolist vector (see alloc.c for both things).
-
- Reloading would work in an Emacs that has just been started; except
- when a switch is specified to inhibit this, it would read the dump
- file and set all the appropriate locations. The data loaded must be
- relocated, but that's not hard. Those locations that are of type
- Lisp_Object can be found by a technique like garbage-collection, and
- those of them that point to storage can be relocated. The other data
- read from the file will not need to be relocated.
-
- The switch to inhibit loading the data base would be used when it
- is time to dump a new data base.
-
- This would take a few seconds, which is much faster than loading
- the Lisp code of Emacs from scratch.
-
-AT&T 3b2, 3b5, 3b15, 3b20 (we32k-att-sysv)
-
- Emacs will probably not work with certain kernel constants too small.
-
- In param.h CDLIMIT should be at least (1L << 12) in order to allow
- processes to write up to 2 Mbyte files. This parameter is configurable
- by normal means in /etc/master.d/kernel; examine that file for the
- symbol CDLIMIT or ULIMIT, and raise it by several powers of 2. Then
- do normal kernel rebuild things via "cd /boot; mkboot -k KERNEL" and so
- forth.
-
- In seg.h NSEGP and STACKSEG should be at least 16 and 4 respectively
- to allow processes with total size of up to 2Mbytes.
- However, I'm told it is unlikely this would fail to be true.
-
- The MAXMEM may also prevent Emacs from running. The file
- 3B-MAXMEM in this directory explains how to increase MAXMEM.
-
- On some of these machines, you may need to define IN_SCCS_ID
- in config.h to make Emacs work. Supposedly you can tell whether
- this is necessary by checking something in /usr/include/sys/time.h;
- we do not know precisely what.
-
-AT&T 7300 or 3b1 (m68k-att-sysv)
-
- 18.52 worked. If you have strange troubles with dumping
- Emacs, delete the last few lines from `src/m/7300.h' and recompile.
- These lines are supposed to produce a sharable executable.
-
- `src/m/7300.h' defines SHORTNAMES because operating system versions
- older than 3.5 did not support long symbol names. Version 3.5 does
- support them, so you can remove the #define SHORTNAMES in that
- version.
-
-Bull DPX/2 models 2nn or 3nn (m68k-bull-sysv3)
-
- Minor fixes merged into 19.19, which should work with CC or GCC.
-
- You should compile with all the POSIX stuff: undef _SYSV and define
- _POSIX_SOURCE, _XOPEN_SOURCE and _BULL_SOURCE.
-
- On bos2.00.45 there is a bug that makes the F_SETOWN fcntl
- call enters in an infinite loop. F_SETOWN_BUG has been defined to avoid
- calling it.
-
-Bull DPX/20 (rs6000-bull-bosx)
-
- Version 19 works.
-
-Bull sps7 (m68k-bull-sysv2)
-
- Changes partially merged in version 19, but some fixes are probably required.
-
-CCI 5/32, 6/32
-
- See "Tahoe".
-
-Celerity (celerity-celerity-bsd4.2)
-
- Version 18.49 worked. This configuration name is a hack, because we
- don't know the processor used by Celerities. If someone
- who uses a Celerity could get in touch with us, we can teach
- config.sub a better name for the configuration.
-
-Clipper (clipper-???)
-
- Version 19 has support for some brand of clipper system. If you
- have successfully built Emacs 19 on some sort of clipper system, let
- us know so we can flesh out this entry.
-
- Note that the Orion 105 is also a clipper, but some system-related
- parameters are different.
-
-Convex (c1-convex-bsd, c2-convex-bsd, c32-convex-bsd, c34-convex-bsd,
- c38-convex-bsd)
-
- Support updated and residual bugs fixed in 19.26.
-
-Cubix QBx/386 (i386-cubix-sysv)
-
- Changes merged in 19.1. Systems before 2/A/0 may fail to compile etags.c
- due to a compiler bug.
-
-Cydra 5 (cydra-cydrome-sysv)
-
- 18.51 worked in one version of their operating system but stopped
- working in a newer version. This has not been fixed.
-
-Data General Aviion (m88k-dg-dgux)
-
- 19.23 works; however, the GCC provided with DGUX 5.4R3.00 fails to
- compile src/emacs.c. GCC 2.5.8 does work.
- The 19.26 pretest was reported to work; no word on which compiler.
-
- System versions other than DGUX 5.4R3.00 have not been tested.
-
-DECstation (mips-dec-ultrix or mips-dec-osf)
-
- This machine is the older Mips-based DECstation.
- Emacs should now work on the Alpha CPU.
-
- 19.25 works on Ultrix 4.2. The 19.26 pretest was reported to work
- on Ultrix 4.2a and on 4.4.
-
- One user reported 19.25 did not work at all with --with-x-toolkit
- using X11R5 patch level 10, but worked ok with X11R5 pl26.
-
- See under Ultrix for problems using X windows on Ultrix.
- Note that this is a MIPS machine.
-
- For Ultrix versions 4.1 or earlier, you may need to define
- SYSTEM_MALLOC in `src/m/pmax.h', because XvmsAlloc.o in libX11.a seems
- to insist on defining malloc itself.
-
- For Ultrix versions prior to 4.0, you may need to delete
- the definition of START_FILES from `src/m/pmax.h'.
-
-Motorola Delta 147 (m68k-motorola-sysv)
-
- The EMacs 19.26 pretest was reported to work.
-
- Motorola Delta boxes running System V/68 release 3.
- Tested on 147 board with SVR3V7, no X and gcc.
- Tested on 167 board with SVR3V7, no X, cc, gnucc and gcc.
- Reports say it works with X too.
-
- The installation script chooses the compiler itself. gnucc is
- preferred.
-
-Motorola Delta 187 (m88k-motorola-sysv,
- m88k-motorola-sysvr4, or
- m88k-motorola-m88kbcs)
-
- The 19.26 pretest was reported to run on SVR3. However, if you
- use --with-x-toolkit on svr3, you will have problems compiling some
- files because time.h and sys/time.h get included twice.
- One fix is to edit those files to protect against multiple inclusion.
-
- As of version 19.13, Emacs was reported to run under SYSVr3 and SYSVr4.
-
-Dual running System V (m68k-dual-sysv)
-
- As of 17.46, this worked except for a few changes
- needed in unexec.c.
-
-Dual running Uniplus (m68k-dual-uniplus)
-
- Worked, as of 17.51.
-
-Elxsi 6400 (elxsi-elxsi-sysv)
-
- Changes for 12.0 release are in 19.1.
- Dumping should work now.
-
-Encore machine (ns16k-encore-bsd)
-
- This machine bizarrely uses 4.2BSD modified to use the COFF format
- for object files. Works (as of 18.40). For the APC processor you
- must enable two lines at the end of `src/s/umax.h', which are commented
- out in the file as distributed.
-
- WARNING: If you compile Emacs with the "-O" compiler switch, you
- must also use the "-q enter_exits" switch so that all functions have
- stack frames. Otherwise routines that call `alloca' all lose.
-
- A kernel bug in some system versions causes input characters to be lost
- occasionally.
-
-GEC 63 (local-gec63-usg5.2)
-
- Changes are partially merged in version 18, but certainly require
- more work. Let us know if you get this working, and we'll give it a
- real configuration name.
-
-Gould Power Node (pn-gould-bsd4.2 or pn-gould-bsd4.3)
-
- 18.36 worked on versions 1.2 and 2.0 of the operating system.
-
- On UTX/32 2.0, use pn-gould-bsd4.3.
-
- On UTX/32 1.2 and UTX/32S 1.0, use pn-gould-bsd4.2 and note that
- compiling `lib-src/sorted-doc' tickles a compiler bug: remove the -g
- flag to cc in the makefile.
-
- UTX/32 1.3 has a bug in the bcopy library routine. Fix it by
- #undef BSTRING in `src/m/gould.h'.
-
- Version 19 incorporates support for releases 2.1 and later of UTX/32.
- A site running a pre-release of 2.1 should #define RELEASE2_1 in config.h.
-
-Gould NP1 (np1-gould-bsd)
-
- Version 19 supposedly works.
-
-Harris Night Hawk (m68k-harris-cxux or m88k-harris-cxux)
-
- This port was added in 19.23. The configuration actually tested was
- a Night Hawk 4800 running CX/UX 7.0.
-
- If you have GCC ported and want to build with it, you probably need to
- change things (like compiler switches) defined in the s/cxux.h file.
-
- With CX/UX 7.0 and later releases, you need to build after setting the
- SDE_TARGET environment variable to COFF (a port using ELF and shared
- libraries has not yet been done).
-
-Honeywell XPS100 (xps100-honeywell-sysv)
-
- Config file added in version 19.
-
-Hewlett-Packard 9000 series 200 or 300 (m68k-hp-bsd or m68k-hp-hpux7.)
-
- Version 19 works under BSD. The 19.26 pretest was reported
- to work on HPUX 9.
-
- These machines are 68000-series CPUs running HP/UX
- (a derivative of sysV with some BSD features) or BSD 4.3 ported by Utah.
- The operating system suffix determines which system Emacs is built for.
-
- Series 200 HPUX runs Emacs only if it has the "HP/UX upgrade".
-
- If you are running HP/UX release 8.0 or later, you need the optional
- "C/ANSI C" software in order to build Emacs (older releases of HP/UX
- do not require any special software). If the file "/etc/filesets/C"
- exists on your machine, you have this software, otherwise you do not.
-
- Note that HP has used two incompatible assembler syntaxes,
- and has recently changed the format of C function frames.
- `src/crt0.c' and `src/alloca.s' have been conditionalised for the new
- assembler and new function-entry sequence. You may need to define
- OLD_HP_ASSEMBLER if you are using an older hpux version. If you
- have an official (bought from HP) series 300 machine you have
- the new assembler. Kernels that are 5.+ or later have new
- assembler. A Series 200 that has been upgraded to a 68010
- processor and a 5.+ kernel has the new compiler.
-
- Define C_SWITCH_MACHINE to be +X to make a version of Emacs that
- runs on both 68010 and 68020 based HP/UX's.
-
- Define HPUX_68010 if you are using the new assembler, for
- a system that has a 68010 without a 68881. This is to say,
- a s200 (upgraded) or s310.
-
- Define the symbol HPUX_NET if you have the optional network features
- that include the `netunam' system call. This is referred to as
- Network Services (NS/9000) in HP literature.
-
-HP 9000 series 500: not supported.
-
- The series 500 has a seriously incompatible memory architecture
- which relocates data in memory during execution of a program,
- and support for it would be difficult to implement.
-
-HP 9000 series 700 or 800 (Spectrum) (hppa1.0-hp-hpux or hppa1.1-hp-hpux
- or ...hpux9shr)
-
- 19.26 is believed to work on HPUX 9 provided you compile with GCC.
- As of version 19.16, Emacs was reported to build (using GCC) and run
- on HP 9000/700 series machines running HP/UX versions 8.07 and 9.01.
-
- Use hppa1.1 for the 700 series and hppa1.0 for the 800
- series machines. (Emacs may not actually care which one you use.)
-
- Use hppa1.1-hp-hpux9shr to use shared libraries on HPUX version 9.
- You may need to create the X libraries libXaw.a and libXmu.a from
- the MIT X distribute, and you may need to edit src/Makefile's
- definition of LIBXT to look like this:
-
- LIBXT= $(LIBW) -lXmu -lXt $(LIBXTR6) -lXext
-
- Some people report trouble using the GNU memory allocator under
- HP/UX version 9. The problems often manifest as lots of ^@'s in the
- buffer.
-
- We are told that these problems go away if you obtain the latest
- patches for the HP/UX C compiler. James J Dempsey
- <jjd@spserv.bbn.com> says that this set of versions works for him:
- /bin/cc:
- HP92453-01 A.09.28 HP C Compiler
- /lib/ccom:
- HP92453-01 A.09.28 HP C Compiler
- HP-UX SLLIC/OPTIMIZER HP-UX.09.00.23 02/18/93
- Ucode Code Generator - HP-UX.09.00.23.5 (patch) 2/18/93
-
- For 700 series machines, the HP-UX patch needed is known as
- PHSS_2653. (Perhaps for 800 series machines as well; we don't
- know.) If you are on the Internet, you should be able to obtain
- this patch by using telnet to access the machine
- support.mayfield.hp.com and logging in as "hpslreg" and following
- the instructions there. Do not ask FSF for further support on
- this. If you have any trouble obtaining the patch, contact HP
- Software Support.
-
- If your buffer fills up with nulls (^@) at some point, it could well
- be that problem. That problem does not happen when people use GCC
- to compile Emacs. On the other hand, the HP compiler version 9.34
- was reported to work for the 19.26 pretest. 9.65 was also reported to work.
-
- If you turn on the DSUSP character (delayed suspend),
- Emacs 19.26 does not know how to turn it off on HPUX.
- You need to turn it off manually.
-
- If you are running HP/UX release 8.0 or later, you need the optional
- "C/ANSI C" software in order to build Emacs (older releases of HP/UX
- do not require any special software). If the file "/etc/filesets/C"
- exists on your machine, you have this software, otherwise you do not.
-
-High Level Hardware Orion (orion-highlevel-bsd)
-
- This is the original microprogrammed hardware.
- Machine description file ought to work.
-
-High Level Hardware Orion 1/05 (clipper-highlevel-bsd)
-
- Changes merged in 18.52. This is the one with the Clipper cpu.
- Note that systems which lack NFS need LOAD_AVE_TYPE changed to `double'.
-
- C compiler has a bug; it loops compiling eval.c.
- Compile it by hand without optimization.
-
-IBM PS/2 (i386-ibm-aix1.1 or i386-ibm-aix1.2)
-
- Changes merged in version 19. You may need to copy
- /usr/lib/samples/hft/hftctl.c to the Emacs src directory.
-
- i386-ibm-aix1.1 may not work with certain new X window managers, and
- may be suboptimal.
-
-IBM RS/6000 (rs6000-ibm-aix)
-
- Emacs 19.26 is believed to work; its pretest was tested.
-
- At last report, Emacs didn't run well on terminals. Informed
- persons say that the tty VMIN and VTIME settings have been
- corrupted; if you have a fix, please send it to us.
-
- Compiling with -O using the IBM compiler has been known
- to make Emacs work incorrectly. It's reported that on
- AIX 3.2.5 with an IBM compiler earlier than 1.03.00.14,
- cc -O fails for some files. You need to install any
- PTF containing APAR #IX42810 to bring the compiler to
- the 1.03.00.14 level to allow optimized compiles.
- Alternatively, recompiling just emacs.c and extents.c
- without optimization seems to do the trick as well.
-
- There are reports that IBM compiler versions earlier than 1.03.00.02
- fail even without -O.
-
- As of 19.11, if you strip the Emacs executable, it ceases to work.
-
- If you are using AIX 3.2.3, you may get a core dump when loading
- ange-ftp. You may be able to fix the problem by defining LIBS_TERMCAP
- as -ltermcap -lcurses. Please tell us if this fails to work.
-
- If anyone can fix the above problems, or confirm that they don't happen
- with certain versions of various programs, we would appreciate it.
-
-IBM RT/PC (romp-ibm-bsd or romp-ibm-aix)
-
- Use romp-ibm-bsd for the 4.2-like system and romp-ibm-aix for AIX.
- 19.22 is reported to work under bsd. We don't know about AIX.
-
- On BSD, if you have trouble, try compiling with a different compiler.
-
- On AIX, the file /usr/lib/samples/hft/hftctl.c must be compiled into
- hftctl.o, with this result left in the src directory (hftctl.c is
- part of the standard AIX distribution).
-
- window.c must not be compiled with -O on AIX.
-
-Integrated Solutions `Optimum V' (m68k-isi-bsd4.2 or -bsd4.3)
-
- 18.52 said to work on some sort of ISI machine.
- Version 18.45 worked (running on a Optimum V (VME bus, 68020)
- BSD 4.2 (3.05e) system). 18.42 is reported to work on
- a Qbus 68010 system. Has not been tried on `WorkStation' `Cluster
- Compute Node' `Cluster WorkStation' or `Server Node' (Love the
- StudLYCaps)
-
- Compilation with -O is rumored to break something.
-
- On recent system versions, you may need to undefine the macro UMAX
- in `lib-src/loadst.c' and `src/getpagesize.h'. They stupidly defined this
- in a system header file, which confuses Emacs (which thinks that UMAX
- indicates the Umax operating system).
-
-Intel 386 (i386-*-isc, i386-*-esix,
- i386-*-xenix, i386-*-linux, i386-*-freebsd,
- i386-intsys-sysv, i386-*-sysv3,
- i386-*-sysv4, i386-*-sysv4.2,
- i386-*-sysv5.3, i386-*-bsd4.2,
- i386-*-sco3.2v4, i386-*-bsd386, i386-*-386bsd
- or i486... or i586...)
-
- In the above configurations, * means that the manufacturer's name
- you specify does not matter, and you can use any name you like
- (but it should not contain any dashes or stars).
-
- When using the ISC configurations, be sure to specify the isc
- version number - for example, if you're running ISC 3.0, use
- i386-unknown-isc3.0 as your configuration name.
- Use i386-*-esix for Esix; Emacs runs as of version 19.6.
- Use i386-*-linux for GNU/Linux systems; Emacs runs as of version 19.26.
- Use i386-intsys-sysv for Integrated Solutions 386 machines.
- It may also be correct for Microport systems.
- Use i386-*-sco3.2v4 for SCO 3.2v4; Emacs runs as of version 19.26.
-
- On GNU/Linux systems, Emacs 19.23 was said to work properly with libc
- version 4.5.21, but not with 4.5.19. If your system uses QMAGIC
- for the executable format, you must edit config.h to define LINUX_QMAGIC.
-
- On GNU/Linux, configure may fail to put these definitions in config.h:
-
- #define HAVE_GETTIMEOFDAY
- #define HAVE_MKDIR
- #define HAVE_RMDIR
-
- To work around the problem, add those definitions by hand.
- It is possible that this problem happens only with X11R6
- or that newer system versions have fixed it.
-
- The 19.26 pretest was reported to work on SVR4.3 and on Freebsd.
-
- Use i386-*-bsd386 for BSDI BSD/386; Emacs runs as of version 19.23.
- Make on that system is broken; use GNU make instead.
- Shell bugs in version 1.0 of BSD/386 cause configure
- to do the wrong thing with --with-x-toolkit; the workaround is to edit
- configure to run another shell such as bash.
-
- For System V release 3, use i386-*-sysv3.
- For System V release 4, use i386-*-sysv4.
- For System V release 4.2, use i386-*-sysv4.2.
-
- If you are using Xenix, see notes at end under Xenix.
- If you are using Esix, see notes at end under Esix.
- If you are using SCO Unix, see notes at end under SCO.
-
- On 386bsd, netbsd and freebsd, you should use GNU make, not the
- system's make. Assuming it's installed as gmake, do `gmake install
- MAKE=gmake'.
-
- If you are using System V release 4.2, you may find that `cc -E'
- puts spurious spaces in `src/xmakefile'. If that happens,
- specify CPP=/lib/cpp as an option when you run make.
- There is no problem if you compile with GCC.
-
- Note that use of Linux with GCC 2.4 and the DLL 4.4 libraries
- requires the experimental "net 2" network patches (no relation to
- Berkeley Net 2). There is a report that (some version of) Linux
- requires including `/usr/src/linux/include/linux' in buffer.c
- but no coherent explanation of why that might be so. If it is so,
- in current versions of Linux, something else should probably be changed.
-
- Some sysV.3 systems seem to have bugs in `opendir';
- for them, alter `config.h' to define NONSYSTEM_DIR_LIBRARY
- and undefine SYSV_SYSTEM_DIR.
-
- If you use optimization on V.3, you may need the option -W2,'-y 0'
- to prevent certain faulty optimization.
-
- On 386/ix, to link with shared libraries, add #define USG_SHARED_LIBRARIES
- to config.h.
-
- On SCO, there are problems in regexp matching when Emacs is compiled
- with the system compiler. The compiler version is "Microsoft C
- version 6", SCO 4.2.0h Dev Sys Maintenance Supplement 01/06/93;
- Quick C Compiler Version 1.00.46 (Beta). The solution is to compile
- with GCC.
-
- On ISC systems (2.02 and more recent), don't try to use the versions
- of X that come with the system; use XFree86 instead.
-
- There is no consistency in the handling of certain system header files
- on V.3.
-
- Some versions have sys/sioctl.h, and require it in sysdep.c.
- But some versions do not have sys/sioctl.h.
- For a given version of the system, this may depend on whether you have
- X Windows or TCP/IP. Define or undefine NO_SIOCTL_H in config.h
- according to whether you have the file.
-
- Likewise, some versions have been known to need sys/ttold.h, sys/stream.h,
- and sys/ptem.h included in sysdep.c. If your system has these files,
- try defining NEED_PTEM_H in config.h if you have trouble without it.
-
- You may find that adding -I/usr/X/include or -I/usr/netinclude or both
- to CFLAGS avoids compilation errors on certain systems.
-
- Some versions convince sysdep.c to try to use `struct tchars'
- but define `struct tc' instead; add `#define tchars tc'
- to config.h to solve this problem.
-
-Iris 2500 and Iris 2500 Turbo (m68k-sgi-iris3.5 or m68k-sgi-iris3.6)
-
- Version 18 was said to work; use m68k-sgi-iris3.5 for system version 2.5
- and m68k-sgi-iris3.6 for system version 3.6.
- Note that the 3030 is the same as the Iris 2500 Turbo.
-
-Iris 4D (mips-sgi-irix[456].*)
-
- 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.
-
-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)
-
- 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
-
-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-sunos4shr, sparc-sun-solaris2.*,
- i386-sun-solaris2.*)
-
- 19.26 is believed to work on Sparcs and Sun 3's. 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'. Use sunos4shr to link with shared libraries
- on Sunos 4.1.
-
- (FSF MACHINES file says use of shared libraries does not work with
- X11R5 or X11R6 on Sunos 4 as of 19.26, but I think this does not
- apply to XEmacs.)
-
- Use `m68k' for the 68000-based Sun boxes, `sparc' for Sparcstations,
- and `i386' for Sun Roadrunners. i386 calls for Sunos4.0.
-
- Do not define the environment variable 'KEEP_STATE' while running
- `configure'.
-
- FSF MACHINES file says the following: (may not apply to XEmacs)
-
- 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
- add -lansi just before -lc. The precise file names depend on the
- compiler version, so we cannot easily arrange to supply them.
-
- On SunOS 4.1.1, do not use /usr/5bin/cc. You can use gcc or/usr/bin/cc.
- Make sure the environment variable LD_LIBRARY_PATH is not defined.
-
- Some people report crashes on SunOS 4.1.3 if SYSTEM_MALLOC is defined.
- Others have reported that Emacs works if SYSTEM_MALLOC is defined, and not
- if it is undefined. So far we do not know why results vary in this way.
- The sources are set up so that SYSTEM_MALLOC is defined; if that crashes,
- or if you want the benefit of the relocating memory allocator, you can
- try enabling the #undef SYSTEM_MALLOC in src/s/sunos4-1-3.h.
-
- On Solaris 2, you need to install patch 100947-02 to fix a system bug.
- Presumably this patch comes from Sun. You must alter the definition of
- LD_SWITCH_SYSTEM if your X11 libraries are not in /usr/openwin/lib.
- You must make sure that /usr/ucblib is not in your LD_LIBRARY_PATH.
-
- On Solaris 2.2, with a multiprocessor SparcCenter 1000, Emacs 19.17 is
- reported to hang sometimes if it exits while it has one or more
- subprocesses (e.g. the `wakeup' subprocess used by `display-time').
- Emacs and its subprocesses become zombies, and in their zombie state
- slow down their host and disable rlogin and telnet. This is most
- likely due to a bug in Solaris 2.2's multiprocessor support,
- rather than an Emacs bug.
-
- On Solaris, do not use /usr/ucb/cc. Use /opt/SUNWspro/bin/cc. Make
- sure that /usr/ccs/bin and /opt/SUNWspro/bin are in your PATH before
- /usr/ucb. (Most free software packages have the same requirement on
- Solaris.)
-
- If you have trouble using open-network-stream, get the distribution
- of `bind' (the BSD name-server), build libresolv.a, and link Emacs
- with -lresolv, by copying the #definition of LIBS_SYSTEM in
- src/s/sunos4-1.h to src/config.h. This problem is due to obsolete
- software in the nonshared standard library.
-
- If you want to use SunWindows, define HAVE_SUN_WINDOWS
- in config.h to enable a special interface called `emacstool'.
- The definition must *precede* the #include "machine.h".
- System version 3.2 is required for this facility to work.
-
- We recommend that you instead use the X window system, which
- has technical advantages, is an industry standard, and is also
- free software. The FSF does not support the SunWindows code;
- we installed it only on the understanding we would not let it
- divert our efforts from what we think is important.
-
- If you are compiling for X windows, and the X window library was
- compiled to use the 68881, then you must edit config.h according
- the comments at the end of `src/m/sun3.h'.
-
- Note that Emacs on a Sun is not really as big as it looks.
- As dumped, it includes around 200k of zeros between the
- original text section and the original data section
- (now remapped as part of the text). These are never
- swapped in.
-
- To build a single Emacs that will run on Sun 2 and Sun 3
- HARDWARE, just build it on the Sun 2.
-
- On Sunos 4.1.3, the word is that Emacs can loop infinitely
- on startup with X due perhaps to a bug in Sunos. Installing all of
- these Sun patches fixes the problem. We don't know which of them
- are really relevant.
-
- 100075-11 100224-06 100347-03 100482-05 100557-02 100623-03 100804-03
- 101080-01 100103-12 100249-09 100496-02 100564-07 100630-02 100891-10
- 101134-01 100170-09 100296-04 100377-09 100507-04 100567-04 100650-02
- 101070-01 101145-01 100173-10 100305-15 100383-06 100513-04 100570-05
- 100689-01 101071-03 101200-02 100178-09 100338-05 100421-03 100536-02
- 100584-05 100784-01 101072-01 101207-01
-
-Tadpole 68K (m68k-tadpole-sysv)
-
- Changes merged in 19.1.
-
- You may need to edit Makefile to change the variables LIBDIR and
- BINDIR from /usr/local to /usr/contrib.
-
- To give movemail access to /usr/mail, you may need to execute
-
- chmod 2755 etc/movemail; chgrp mail etc/movemail
-
-Tahoe (tahoe-tahoe-bsd4.2 or tahoe-tahoe-bsd4.3)
-
- 18.52 was known to work on some Tahoes, but a compiler bug intervenes
- on others. Some Emacs versions have worked in Unisys 1r4
- (not in 1r3) and CCI I.21.
-
- If you have trouble compiling `lib-src/loadst.c', turn off the definition
- of DKSTAT_HEADER_FILE in `src/m/tahoe.h'.
-
-Tandem Integrity S2 (mips-tandem-sysv)
-
- Changes merged in 18.56 but subprocess support is turned off.
- You will probably want to see if you can make subprocesses work.
-
- You must edit `lib-src/Makefile' to define LOADLIBES = -mld.
-
-Tektronix XD88 (m88k-tektronix-sysv3*)
-
- The 19.26 pretest was reported to work.
- Minor changes merged in 19.19.
-
-Tektronix 16000 box (6130?) (ns16k-tektronix-bsd)
-
- Emacs 17.61 worked.
-
-Tektronix 4300 (m68k-tektronix-bsd)
-
- Emacs 19.26 pretest reported to work.
-
-Titan P2 or P3 (titan-titan-sysv)
-
- Changes probably merged in version 19.
-
-Ustation E30 (SS5E) (m68k-unisys-unipl)
-
- Changes merged in 18.52; don't know whether they work.
-
-Vaxen running Berkeley Unix (vax-dec-bsd4.1, vax-dec-bsd4.2, vax-dec-bsd4.3),
- Ultrix (vax-dec-ultrix),
- System V (vax-dec-sysv0, vax-dec-sysv2), or
- VMS (vax-dec-vms)
-
- Works.
-
- See under Ultrix for problems using X windows on Ultrix (vax-dec-ultrix).
-
- 18.27 worked on System V rel 2 (vax-dec-sysv2).
-
- 18.36 worked on System V rel 0 (vax-dec-sysv0).
-
- Richard Levitte <levitte@e.kth.se> distributes a set of patches to
- Emacs 18.59 to make it work nicely under VMS. Emacs 19 probably
- won't work very well, or even compile. Levitte is working on a
- port, so these problems should be fixed in the near future.
-
-Whitechapel MG1 (ns16k-whitechapel-?)
-
- May work. Supposedly no changes were needed except in `src/m/mg1.h'
- file. I do not know what Unix version runs on them.
-
-Wicat (m68k-wicat-sysv)
-
- Changes merged as of 18.6; whether they work is unknown.
- See comments in `src/m/wicat.h' for things you should change
- depending on the system and compiler version you have.
-\f
-Here are notes about some of the systems supported:
-
-Berkeley 4.1 (bsd4.1)
-
- Works on vaxes.
-
-Berkeley 4.2 (bsd4.2)
-
- Works on several machines.
-
-Berkeley 4.3 (bsd4.3)
-
- Works, on Vaxes at least.
-
-Esix
-
- The following was written for Emacs 18.59 and has been
- slightly adapted for Emacs 19. It may need more change to be correct.
-
- Use s/usg5-4.h for Esix System V 4.0.[34] systems if you also have
- XFree86. If you insist on using the Esix X Window libraries, good
- luck. s/esix5r4.h provides a starting point, but doesn't seem to
- work consistently. The basic problems involve the need to load
- -lX11 *last* in the link command, and even then some things break.
- You get best results by installing XFree86 and forgetting about the
- Esix stuff unless you want to run IXI xdt3, which really only needs
- the Esix X11 shared libraries.
-
- To compile with XFree86, make sure that your LD_LIBRARY_PATH
- contains /usr/X386/lib. Be careful if you also have the Esix X
- Window libraries that /usr/X386/lib appears *first* in the
- LD_LIBRARY_PATH. Then define C_SWITCH_X_SYSTEM -I/usr/X386/include.
-
-Microport
-
- See under "Intel 386".
-
-SCO Unix
- If you have TCP but not X, you need to edit src/s/sco4.h
- to define HAVE_SOCKETS.
-
- If you are using MMDF instead of sendmail, you need to remove
- /usr/lib/sendmail or modify lisp/paths.el before compiling.
- lisp/paths.el (which is loaded during the build) will attempt to use
- sendmail if it exists.
-
- If you are using SMAIL, you need to define the macro
- SMAIL in config.h.
-
-System V rel 0 (usg5.0)
-
- Works, on Vaxes and 3bxxx's.
- There are some problems in 18.37 due to shortnames/cccp problems:
- use the emacs 17 cpp if you have it.
-
-System V rel 2 (usg5.2)
-
- Works on various machines.
- On some (maybe all) machines the library -lPW exists and contains
- a version of `alloca'. On these machines, to use it, put
- #define HAVE_ALLOCA
- #define LIB_STANDARD -lPW -lc
- in the `src/m/MACHINENAME.h' file for the machine.
-
- If you find that the character Meta-DEL makes Emacs crash,
- find where function init_sys_modes in sysdep.c sets sg.c_cc[VQUIT]
- and make it store 7 there. I have as yet no evidence of whether
- this problem, known in HP/UX, exists in other system V versions.
-
-System V rel 2.2 (usg5.2.2)
-
- In 5.2.2 AT&T undid, incompatibly, their previous incompatible
- change to the way the nlist library is called. A different s- file
- is used to enable the other interface.
-
- They call themselves the right choice--can't they choose?
-
- Emacs version 18 unexec is currently not working properly
- on 5.2.2. Nobody knows why yet. A workaround is to define
- NO_REMAP. It is not yet known whether this applies to all
- machines running 5.2.2.
-
-System V rel 3 (usg5.3)
-
- Some versions of this system support ptys and BSD-style sockets.
- On such systems, you should define HAVE_PTYS and HAVE_SOCKETS in config.h.
-
- If you want to link Emacs with shared libraries, define
- USG_SHARED_LIBRARIES.
-
- You may have to add ANSI idempotence #-lines to your sys/types.h
- file to get Emacs to compile correctly. This may be necessary on
- other pre-ANSI systems as well.
-
- On an AT&T 6386WGS using System V Release 3.2 and X11R3, the X support
- cannot be made to work. Whether or not the GNU relocating malloc is
- used, the symptom is that the first call Emacs makes to sbrk(0) returns
- (char *)-1. Sorry, you're stuck with character-only mode. Try
- installing Xfree86 to fix this.
-
-System V rel 4.0.3 and 4.0.4 (usg5.4)
-
- Supported, including shared libraries for ELF, but ptys do not work
- because TIOCGPGRP fails to work on ptys (but Dell 2.2 seems to have
- fixed this). This failure is probably due to a misunderstanding of
- the consequences of the POSIX spec: many system designers mistakenly
- think that POSIX requires this feature to fail. This is untrue;
- ptys are an extension, and POSIX says that extensions *when used*
- may change the action of standard facilities in any fashion.
-
- If you get compilation errors about wrong number of
- arguments to getpgrp, define GETPGRP_NO_ARG.
-
- The standard C preprocessor may generate xmakefile incorrectly. However,
- /lib/cpp will work, so use `make CPP=/lib/cpp'. Standard cpp
- seems to work OK under Dell 2.2.
-
- Some versions 3 and earlier of V.4, on the Intel 386 and 860, had
- problems in the X11 libraries. These prevent Emacs from working
- with X. You can use Emacs with X provided your copy of X is based
- on X11 release 4 or newer, or is Dell's 2.2 (which is a 4.0.3).
- Unfortunately, the only way you can tell whether your X11 library is
- new enough is to try compiling Emacs to use X. If emacs runs, your
- X11 library is new enough.
-
- In this context, GSV4 and GSV4i are alternate names for X11R4.
- OL2.* is X11R3 based. OL3 is in between X11R3 and X11R4, and may or
- may not work, depending on who made the Unix system. If the library
- libXol is part of the X distribution, then you have X11R3 and Emacs
- won't work with X.
-
- Most versions of V.4 support sockets. If `/usr/lib/libsocket.so'
- exists, your system supports them. If yours does not, you must add
- #undef HAVE_SOCKETS in config.h, after the inclusion of s-usg5-4.h.
- (Any system that supports Internet should implement sockets.)
-
-Ultrix (bsd4.3)
-
- Recent versions of Ultrix appear to support the features of Berkeley 4.3.
- Ultrix was at the BSD 4.2 level for a long time after BSD 4.3 came out.
-
- Ultrix 3.0 has incompatibilities in its X library if you have the
- Ultrix version of X (UWS version 2.0). To solve them, you need to
- prevent XvmsAlloc.o in Xlib from being used. Israel Pinkas says:
-
- I added the following lines to config.h after the X defines:
-
- #if defined(ultrix) && defined(X11)
- #define OBJECTS_SYSTEM calloc.o
- #endif
-
- Then I ran the following:
-
- ar x /usr/lib/libc.a calloc.o
-
- The problem is said to be gone in UWS version 2.1.
-
-Uniplus 5.2 (unipl5.2)
-
- Works, on Dual machines at least.
-
-VMS (vmsM.N)
-
- Richard Levitte <levitte@e.kth.se> distributes a set of patches to
- Emacs 18.59 to make it work nicely under VMS. Emacs 19 probably
- won't work very well, or even compile. Levitte is working on a
- port, so these problems should be fixed in the near future.
-
- Note that Emacs for VMS is usually distributed in a special VMS
- distribution. See the file ../vms/VMSINSTALL for info on moving
- Unix distributions to VMS, and other VMS-related topics.
-
-Xenix (xenix)
-
- Should work in 18.50, but you will need to edit the files
- `lib-src/Makefile' and `src/ymakefile'
- (see the comments that mention "Xenix" for what to change.)
- Compiling Emacs with -O is said not to work.
-
- If you want Emacs to work with Smail (installed as /usr/bin/smail)
- then add the line #define SMAIL to config.h.
-
- The file etc/XENIX suggests some useful things to do to Xenix
- to make the Emacs meta key work.
-\f
-Local variables:
-mode: indented-text
-fill-prefix: " "
-End:
+VMS has never been supported by XEmacs. In fact, all the old VMS code
+inherited from Emacs has been removed. Sorry, all you VMS fans out there.
projects / chise / xemacs-chise.git.1 / blobdiff