This file describes various problems that have been encountered
in compiling, installing and running XEmacs. It has been updated for
-XEmacs 21.0.
+XEmacs 21.5.
This file is rather large, but we have tried to sort the entries by
their respective relevance for XEmacs, but may have not succeeded
Also, Try finding the things you need using one of the search commands
XEmacs provides (e.g. `C-s').
-A general advice:
- WATCH OUT for .emacs file! ~/.emacs is your Emacs init file. If
- you observe strange problems, invoke XEmacs with the `-q' option
- and see if you can repeat the problem.
+General advice:
+
+ WATCH OUT for your init file! (~/.xemacs/init.el or ~/.emacs) If
+ you observe strange problems, invoke XEmacs with the `-vanilla'
+ option and see if you can repeat the problem.
+
+ Note that most of the problems described here manifest at RUN
+ time, even those described as BUILD problems. It is quite unusual
+ for a released XEmacs to fail to build. So a "build problem"
+ requires you to tweak the build environment, then rebuild XEmacs.
+ A "runtime problem" is one that can be fixed by proper
+ configuration of the existing build. Compatibility problems and
+ Mule issues are generally runtime problems, but are treated
+ separately for convenience.
* Problems with building XEmacs
===============================
** General
-*** Don't use -O2 with gcc 2.8.1 and egcs 1.0 under SPARC architectures
-without also using `-fno-schedule-insns'.
-gcc will generate incorrect code otherwise, typically resulting in
-crashes in the function skip-syntax-backward.
+ Much general information is in INSTALL. If it's covered in
+ INSTALL, we don't repeat it here.
-*** egcs-1.1
+*** X11/bitmaps/gray (or other X11-related file) not found.
-There have been reports of egcs-1.1 not compiling XEmacs correctly on
-Alpha Linux. There have also been reports that egcs-1.0.3a is O.K.
+The X11R6 distribution was monolithic, but the X11R7 distribution is
+much more modular. Many OS distributions omit these bitmaps (assuming
+nobody uses them, evidently). Your OS distribution should have a
+developer's package containing these files, probably with a name
+containing the string "bitmap". Known package names (you may need to
+add an extension such as .deb or .rpm) include x11/xbitmaps (Ubuntu)
+and xorg-x11-xbitmaps (Fedora Core 5).
-*** Don't use -O2 or -O3 with Cygwin 1.0, CodeFusion-99070 or gcc 2.7.2 on x86
-without also using `-fno-strength-reduce'.
+*** How do I configure to get the buffer tabs/progress bars?
-gcc will generate incorrect code otherwise. This bug is present in at
-least 2.6.x and 2.7.[0-2]. This bug has been fixed in GCC 2.7.2.1 and
-later. This bug is O/S independent, but is limited to x86 architectures.
+These features depend on support for "native widgets". Use the
+--with-widgets option to configure. Configuration of widgets is
+automatic for "modern" toolkits (MS Windows, GTK, and Motif), but if
+you are using Xt and the Athena widgets, you will probably want to
+specify a "3d" widget set. See configure --usage, and don't forget to
+install the corresponding development libraries.
-This problem is known to be fixed in egcs (or pgcc) 1.0 or later.
+*** I know I have libfoo installed, but configure doesn't find it.
-Unfortunately, later releases of Cygnus-released compilers (not the
-Net-released ones) have a bug with the same `problem signature'.
-
-If you're lucky, you'll get an error while compiling that looks like:
-
-event-stream.c:3189: internal error--unrecognizable insn:
-(insn 256 14 15 (set (reg/v:SI 24)
- (minus:SI (reg/v:SI 25)
- (const_int 2))) -1 (insn_list 11 (nil))
- (nil))
- 0 0 [main]
-
-If you're unlucky, your code will simply execute incorrectly.
-
-*** Don't use gcc-2.95.2 with -mcpu=ultrasparc on Solaris 2.6.
-
-gcc will assume a 64-bit operating system, even though you've
-merely told it to assume a 64-bit instruction set.
-
-*** Don't use -O2 with gcc 2.7.2 under Intel architectures without also
-using `-fno-caller-saves'.
-
-gcc will generate incorrect code otherwise. This bug is still
-present in gcc 2.7.2.3. There have been no reports to indicate the
-bug is present in egcs 1.0 (or pgcc 1.0) or later. This bug is O/S
-independent, but limited to x86 architectures.
-
-This problem is known to be fixed in egcs (or pgcc) 1.0 or later.
+Typical of Linux systems with package managers. To link with a shared
+library, you only need the shared library. To compile objects that
+link with it, you need the headers---and distros don't provide them with
+the libraries. You need the additional "development" package, too.
*** When using gcc, you get the error message "undefined symbol __fixunsdfsi".
When using gcc, you get the error message "undefined symbol __main".
This will rebuild all the needed .elc files.
+** Intel Architecture General
+
+*** Don't use -O2 or -O3 with Cygwin 1.0, CodeFusion-99070 or gcc 2.7.2 on x86
+without also using `-fno-strength-reduce'.
+
+gcc will generate incorrect code otherwise. This bug is present in at
+least 2.6.x and 2.7.[0-2]. This bug has been fixed in GCC 2.7.2.1 and
+later. This bug is O/S independent, but is limited to x86 architectures.
+
+This problem is known to be fixed in egcs (or pgcc) 1.0 or later.
+
+Unfortunately, later releases of Cygnus-released compilers (not the
+Net-released ones) have a bug with the same `problem signature'.
+
+If you're lucky, you'll get an error while compiling that looks like:
+
+event-stream.c:3189: internal error--unrecognizable insn:
+(insn 256 14 15 (set (reg/v:SI 24)
+ (minus:SI (reg/v:SI 25)
+ (const_int 2))) -1 (insn_list 11 (nil))
+ (nil))
+ 0 0 [main]
+
+If you're unlucky, your code will simply execute incorrectly.
+
+*** Don't use -O2 with gcc 2.7.2 under Intel architectures without also
+using `-fno-caller-saves'.
+
+gcc will generate incorrect code otherwise. This bug is still
+present in gcc 2.7.2.3. There have been no reports to indicate the
+bug is present in egcs 1.0 (or pgcc 1.0) or later. This bug is O/S
+independent, but limited to x86 architectures.
+
+This problem is known to be fixed in egcs (or pgcc) 1.0 or later.
+
*** `compress' and `uncompress' not found and XFree86
XFree86 installs a very old version of libz.a by default ahead of where
libz.a in the X11 binary directory.
+** Motif
+
+Motif is the X11 version of the Gnus torture test: if there's a way to
+crash, Motif will find it. With the open source release of Motif, it
+seems like a good idea to collect all Motif-related issues in one
+place.
+
+You should also look in your OS's section, as it may not be Motif's
+fault.
+
+*** XEmacs visibly repaints itty-bitty rectangles very slowly.
+
+This should only be visible on a slow X connection (ISDN, maybe T1).
+
+At least some versions of Motif apparently do not implement
+XtExposeCompressMaximal properly, so it is disabled. If you wish to
+experiment, you can remove the #ifdef LWLIB_NEEDS_MOTIF at line 238
+(or so) of src/EmacsFrame.c, leaving only the line
+
+ /* compress_exposure */ XtExposeCompressMaximal | XtExposeNoRegion,
+
+and recompile. This enables exposure compression, giving a 10:1 or
+better speedup for some users. However, on some Motif platforms (Red
+Hat Linux 9.0 and Solaris 2.8, at least), this causes XEmacs to hang
+while displaying the progress bar (eg, in font-lock). A workaround
+for that problem is to setq `progress-feedback-use-echo-area' to `t'.
+
+*** XEmacs crashes on exit (#1).
+
+The backtrace is something like:
+
+ (gdb) where
+ #0 0xfeb9a480 in _libc_kill () from /usr/lib/libc.so.1
+ #1 0x000b0388 in fatal_error_signal ()
+ #2 <signal handler called>
+ #3 YowIter (ht=0xb, id=0x0, v=0x74682074, client=0x47e3c0)
+ at ImageCache.c:1159
+ #4 0xff26cc5c in _LTHashTableForEachItem (ht=0x4725e8,
+ iter=0xff26dda0 <YowIter>, ClientData=0x47e3c0) at Hash.c:671
+ #5 0xff2a4664 in destroy (w=0x496550) at Screen.c:352
+ #6 0xfef92118 in Phase2Destroy () from /usr/openwin/lib/libXt.so.4
+ #7 0xfef91940 in Recursive () from /usr/openwin/lib/libXt.so.4
+ #8 0xfef91e44 in XtPhase2Destroy () from /usr/openwin/lib/libXt.so.4
+ #9 0xfef91ae8 in _XtDoPhase2Destroy () from /usr/openwin/lib/libXt.so.4
+ #10 0xfef918cc in XtDestroyWidget () from /usr/openwin/lib/libXt.so.4
+ #11 0xfef91438 in CloseDisplay () from /usr/openwin/lib/libXt.so.4
+ #12 0xfef91394 in XtCloseDisplay () from /usr/openwin/lib/libXt.so.4
+ #13 0x0025b8b0 in x_delete_device ()
+ #14 0x000940b0 in delete_device_internal ()
+ #15 0x000806a0 in delete_console_internal ()
+
+This is known to happen with Lesstif version 0.93.36. Similar
+backtraces have also been observed on HP/UX and Solaris. There is a
+patch for Lesstif. (This is not a solution; it just stops the crash.
+It may or may not be harmless, but "it works for the author".)
+
+Note that this backtrace looks a lot like the one in the next item.
+However, this one is invulnerable to the Solaris patches mentioned there.
+
+Frank McIngvale <frankm@hiwaay.net> says:
+
+ Ok, 0.93.34 works, and I tracked down the crash to a section
+ marked "experimental" in 0.93.36. Patch attached, "works for me".
+
+diff -u -r lesstif-0.93.36/lib/Xm/ImageCache.c lesstif-0.93.36-mod/lib/Xm/ImageCache.c
+--- lesstif-0.93.36/lib/Xm/ImageCache.c 2002-08-05 14:53:24.000000000 -0500
++++ lesstif-0.93.36-mod/lib/Xm/ImageCache.c 2002-11-11 11:13:12.000000000 -0600
+@@ -1166,5 +1166,4 @@
+ DEBUGOUT(_LtDebug0(__FILE__, NULL, "_LtImageCacheScreenDestroy (XmGetPixmapByDepth) %p\n",
+ s));
+
+- (void) _LTHashTableForEachItem(PixmapCache, YowIter, (XtPointer)s);
+ }
+
+*** XEmacs crashes on exit (#2)
+
+Especially frequent with multiple frames. Crashes that produce C
+backtraces like this:
+
+#0 0xfec9a118 in _libc_kill () from /usr/lib/libc.so.1
+#1 0x77f48 in fatal_error_signal (sig=11)
+ at /codes/rpluim/xemacs-21.4/src/emacs.c:539
+#2 <signal handler called>
+#3 0xfee929f4 in XFindContext () from /usr/openwin/lib/libX11.so.4
+#4 0xfee92930 in XFindContext () from /usr/openwin/lib/libX11.so.4
+#5 0xff297e54 in DisplayDestroy () from /usr/dt/lib/libXm.so.4
+#6 0xfefbece0 in XtCallCallbackList () from /usr/openwin/lib/libXt.so.4
+#7 0xfefc486c in XtPhase2Destroy () from /usr/openwin/lib/libXt.so.4
+#8 0xfefc45d0 in _XtDoPhase2Destroy () from /usr/openwin/lib/libXt.so.4
+#9 0xfefc43b4 in XtDestroyWidget () from /usr/openwin/lib/libXt.so.4
+#10 0x15cf9c in x_delete_device (d=0x523f00)
+
+are caused by buggy Motif libraries. Installing the following patches
+has been reported to solve the problem on Solaris 2.7:
+
+107081-40 107656-07
+
+For information (although they have not been confirmed to work), the
+equivalent patches for Solaris 2.8 are:
+
+108940-33 108652-25
+
+*** On HP-UX 11.0 XEmacs causes excessive X11 errors when running.
+ (also appears on AIX as reported in comp.emacs.xemacs)
+
+Marcus Thiessel <marcus@xemacs.org>
+
+ Unfortunately, XEmacs releases prior to 21.0 don't work with
+ Motif2.1. It will compile but you will get excessive X11 errors like
+
+ xemacs: X Error of failed request: BadGC (invalid GC parameter)
+
+ and finally XEmacs gets killed. A workaround is to use the
+ Motif1.2_R6 libraries. You can the following line to your call to
+ configure:
+
+ --x-libraries="/usr/lib/Motif1.2_R6 -L/usr/lib/X11R6"
+
+ Make sure /usr/lib/Motif1.2_R6/libXm.sl is a link to
+ /usr/lib/Motif1.2_R6/libXm.3.
+
+*** On HP-UX 11.0: Object "" does not have windowed ancestor
+
+Marcus Thiessel <marcus@xemacs.org>
+
+ XEmacs dies without core file and reports:
+
+ Error: Object "" does not have windowed ancestor.
+
+ This is a bug. Please apply the patch PHSS_19964 (check if
+ superseded). The other alternative is to link with Motif1.2_R6 (see
+ previous item).
+
+*** Motif dialog boxes lose on Irix.
+
+Larry Auton <lda@control.att.com> writes:
+Beware of not specifying
+
+ --with-dialogs=athena
+
+if it builds with the motif dialogs [boom!] you're a dead man.
+
+
** AIX
+*** IBM compiler fails: "The character # is not a valid C source character."
+
+Most recently observed in 21.5.9, due to USE_KKCC ifdefs (they just
+happen to tickle the implementation).
+
+Valdis Kletnieks says:
+
+ The problem is that IBM defines a *MACRO* called 'memcpy', and we
+ have stuck a #ifdef/#endif inside the macro call. As a workaround,
+ try adding '-U__STR__' to your CFLAGS - this will cause string.h to
+ not do a #define for strcpy() to __strcpy() - it uses this for
+ automatic inlining support.
+
+ (For the record, the same issue affects a number of other functions
+ defined in string.h - basically anything the compiler knows how to
+ inline.)
+
*** On AIX 4.3, you must specify --with-dialogs=athena with configure
*** The libXt shipped with AIX 4.3 up to 4.3.2 is broken. This causes
** SunOS/Solaris
+*** Don't use -O2 with gcc 2.8.1 and egcs 1.0 under SPARC architectures
+without also using `-fno-schedule-insns'.
+
+gcc will generate incorrect code otherwise, typically resulting in
+crashes in the function skip-syntax-backward.
+
+*** Don't use gcc-2.95.2 with -mcpu=ultrasparc on Solaris 2.6.
+
+gcc will assume a 64-bit operating system, even though you've
+merely told it to assume a 64-bit instruction set.
+
+*** Dumping error when using GNU binutils / GNU ld on a Sun.
+
+Errors similar to the following:
+
+ Dumping under the name xemacs unexec():
+ dldump(/space/rpluim/xemacs-obj/src/xemacs): ld.so.1: ./temacs:
+ fatal: /space/rpluim/xemacs-obj/src/xemacs: unknown dynamic entry:
+ 1879048176
+
+are caused by using GNU ld. There are several workarounds available:
+
+In XEmacs 21.2 or later, configure using the new portable dumper
+(--pdump).
+
+Alternatively, you can link using the Sun version of ld, which is
+normally held in /usr/ccs/bin. This can be done by one of:
+
+- building gcc with these configure flags:
+ configure --with-ld=/usr/ccs/bin/ld --with-as=/usr/ccs/bin/as
+
+- adding -B/usr/ccs/bin/ to CFLAGS used to configure XEmacs
+ (Note: The trailing '/' there is significant.)
+
+- uninstalling GNU ld.
+
+The Solaris2 FAQ claims:
+
+ When you install gcc, don't make the mistake of installing
+ GNU binutils or GNU libc, they are not as capable as their
+ counterparts you get with Solaris 2.x.
+
*** Link failure when using acc on a Sun.
To use acc, you need additional options just before the libraries, such as
There have been reports of Sun sed truncating very lines in the
Makefile during configuration. The workaround is to use GNU sed or,
-even better, think of a better way to generate Makefile, and send us a
+even better, think of a better way to generate Makefile, and send us a
patch. :-)
*** On Solaris 2 I get undefined symbols from libcurses.a.
This only occurs if you have LANG != C. This is a known bug with
/bin/sh fixed by installing Patch-ID# 101613-01. Or, you can use
-bash, as a workaround.
+bash by setting the environment variable CONFIG_SHELL to /bin/bash
+
+*** Solaris 2.x configure fails: ./config.status: test: argument expected
+
+This is a known bug with /bin/sh and /bin/test, i.e. they do not
+support the XPG4 standard. You can use bash as a workaround or an
+XPG4-compliant Bourne shell such as the Sun-supplied /usr/xpg4/bin/sh
+by setting the environment variable CONFIG_SHELL to /usr/xpg4/bin/sh
*** On SunOS, you get linker errors
- ld: Undefined symbol
+ ld: Undefined symbol
_get_wmShellWidgetClass
_get_applicationShellWidgetClass
*** On a Sun running SunOS 4.1.1, you get this error message from GNU ld:
- /lib/libc.a(_Q_sub.o): Undefined symbol __Q_get_rp_rd referenced from text segment
+ /lib/libc.a(_Q_sub.o): Undefined symbol __Q_get_rp_rd referenced from text segment
The problem is in the Sun shared C library, not in GNU ld.
*** SunOS 4.1.2: undefined symbol _get_wmShellWidgetClass
Apparently the version of libXmu.so.a that Sun ships is hosed: it's missing
- some stuff that is in libXmu.a (the static version). Sun has a patch for
+ some stuff that is in libXmu.a (the static version). Sun has a patch for
this, but a workaround is to use the static version of libXmu, by changing
the link command from "-lXmu" to "-Bstatic -lXmu -Bdynamic". If you have
OpenWindows 3.0, ask Sun for these patches:
broken. Use the ones in /usr/openwin/{include,lib} instead.
** Linux
+
+See also Intel Architecture General, above.
+
+*** egcs-1.1 on Alpha Linux
+
+There have been reports of egcs-1.1 not compiling XEmacs correctly on
+Alpha Linux. There have also been reports that egcs-1.0.3a is O.K.
+
*** Under Linux, you get "too many arguments to function `getpgrp'".
You have probably installed LessTiff under `/usr/local' and `libXm.so'
an earlier version. The solution is to upgrade your old library.
** IRIX
+
+*** More coredumping in Irix (6.5 known to be vulnerable)
+
+No fix is known yet. Here's the best information we have:
+
+Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes:
+
+ Were xemacs and [any 3rd party, locally-compiled] libraries [you use]
+ all compiled with the same ABI ( -o32, -n32, -64) and
+ mips2/mips3/mips4 flags, and are they appropriate for the machine in
+ question? I know the IP30 implies an Octane, so it should be an R10K
+ chipset and above such nonsense, but I've seen the most astoundingly
+ bizzare crashes when somebody managed to compile with -mips4 and get
+ it to run on an R4400 or R5K system. ;)
+
+ Also, since you're using gcc, try re-running fixincludes and *then*
+ rebuilding xemacs and [any] libraries - mismatched headers can do that
+ sort of thing to you with little or no clue what's wrong (often you
+ get screwed when one routine does an malloc(sizeof(foo_struct)) and
+ passes the result to something that things foo_struct is a bit bigger,
+ trashing memory....
+
+Here's typical crash backtrace. With --pdump, this occurs usually at
+startup under X windows and xemacs -nw at least starts, while without
+--pdump a similar crash is observed during build.
+
+#0 0x0fa460b8 in kill () at regcomp.c:637
+637 regcomp.c: No such file or directory.
+ in regcomp.c
+(gdb) where
+#0 0x0fa460b8 in kill () at regcomp.c:637
+#1 0x10087f34 in fatal_error_signal ()
+(gdb) quit
+
+This is confusing because there is no such file in the XEmacs
+distribution. This is seen on (at least) the following configurations:
+
+uname -a: IRIX64 oct202 6.5 01091821 IP30
+XEmacs 21.4.9 "Informed Management" configured for `mips-sgi-irix6.5'.
+XEmacs 21.5-b9 "brussels sprouts" configured for `mips-sgi-irix6.5'.
+
+*** On Irix 6.5, the MIPSpro compiler gets an internal compiler error
+
+The MIPSpro Compiler (at least version 7.2.1) can't seem to handle the
+union type properly, and fails to compile src/glyphs.c. To avoid this
+problem, always build ---use-union-type=no (but that's the default, so
+you should only see this problem if you're an XEmacs maintainer).
+
*** Linking with -rpath on IRIX.
Darrell Kindred <dkindred@cmu.edu> writes:
1. The ld in IRIX 5.3 ignores all but the last -rpath
spec, so the patched configure spits out a warning
if --x-libraries or --site-runtime-libraries are
- specified under irix 5.x, and it only adds -rpath
+ specified under irix 5.x, and it only adds -rpath
entries for the --site-runtime-libraries. This bug was
fixed sometime between 5.3 and 6.2.
This might be a sed problem. For your own safety make sure to use
GNU sed while dumping XEmacs.
-*** On HP-UX 11.0 XEmacs causes excessive X11 errors when running.
- (also appears on AIX as reported in comp.emacs.xemacs)
-
-Marcus Thiessel <marcus@xemacs.org>
-
- Unfortunately, XEmacs releases prior to 21.0 don't work with
- Motif2.1. It will compile but you will get excessive X11 errors like
-
- xemacs: X Error of failed request: BadGC (invalid GC parameter)
-
- and finally XEmacs gets killed. A workaround is to use the
- Motif1.2_R6 libraries. You can the following line to your call to
- configure:
-
- --x-libraries="/usr/lib/Motif1.2_R6 -L/usr/lib/X11R6"
-
- Make sure /usr/lib/Motif1.2_R6/libXm.sl is a link to
- /usr/lib/Motif1.2_R6/libXm.3.
-
-*** On HP-UX 11.0: Object "" does not have windowed ancestor
-
-Marcus Thiessel <marcus@xemacs.org>
-
- XEmacs dies without core file and reports:
-
- Error: Object "" does not have windowed ancestor.
-
- This is a bug. Please apply the patch PHSS_19964 (check if
- superseded). The other alternative is to link with Motif1.2_R6 (see
- previous item).
-
** SCO OpenServer
*** Native cc on SCO OpenServer 5 is now OK. Icc may still throw you
a curve. Here is what Robert Lipe <robertl@arnet.com> says:
-Unlike XEmacs 19.13, building with the native cc on SCO OpenServer 5
+Unlike XEmacs 19.13, building with the native cc on SCO OpenServer 5
now produces a functional binary. I will typically build this
configuration for COFF with:
--site-includes=/usr/local/include --site-libraries=/usr/local/lib \
--with-xpm --with-xface --with-sound=nas
-This version now supports ELF builds. I highly recommend this to
-reduce the in-core footprint of XEmacs. This is now how I compile
+This version now supports ELF builds. I highly recommend this to
+reduce the in-core footprint of XEmacs. This is now how I compile
all my test releases. Build it like this:
/path_to_XEmacs_source/configure --with-gcc=no \
--site-includes=/usr/local/include --site-libraries=/usr/local/lib \
--with-xpm --with-xface --with-sound=nas --dynamic
-The compiler known as icc [ supplied with the OpenServer 5 Development
+The compiler known as icc [ supplied with the OpenServer 5 Development
System ] generates a working binary, but it takes forever to generate
XEmacs. ICC also whines more about the code than /bin/cc does. I do
believe all its whining is legitimate, however. Note that you do
--site-includes=/usr/local/include --site-libraries=/usr/local/lib \
--with-xpm --with-xface --with-sound=nas --dynamic --compiler="icc"
-NOTE I have the xpm, xface, and audio libraries and includes in
+NOTE I have the xpm, xface, and audio libraries and includes in
/usr/local/lib, /usr/local/include. If you don't have these,
don't include the "--with-*" arguments in any of my examples.
-In previous versions of XEmacs, you had to override the defaults while
+In previous versions of XEmacs, you had to override the defaults while
compiling font-lock.o and extents.o when building with icc. This seems
to no longer be true, but I'm including this old information in case it
resurfaces. The process I used was:
- make -k
- [ procure pizza, beer, repeat ]
+ make -k
+ [ procure pizza, beer, repeat ]
cd src
make CC="icc -W0,-mP1COPT_max_tree_size=3000" font-lock.o extents.o
make LD=icc
-If you want sound support, get the tls566 supplement from
-ftp.sco.com:/TLS or any of its mirrors. It works just groovy
+If you want sound support, get the tls566 supplement from
+ftp.sco.com:/TLS or any of its mirrors. It works just groovy
with XEmacs.
The M-x manual-entry is known not to work. If you know Lisp and would
like help in making it work, e-mail me at <robertl@dgii.com>.
(UNCHECKED for 19.15 -- it might work).
-In earlier releases, gnuserv/gnuclient/gnudoit would open a frame
+In earlier releases, gnuserv/gnuclient/gnudoit would open a frame
just fine, but the client would lock up and the server would
-terminate when you used C-x # to close the frame. This is now
+terminate when you used C-x # to close the frame. This is now
fixed in XEmacs.
In etc/ there are two files of note. emacskeys.sco and emacsstrs.sco.
Note: Much of the above entry is probably not valid for XEmacs 21.0
and later.
+** Windows
+
+*** XEmacs complains "No such file or directory, diff"
+
+or "ispell" or other commands that seem related to whatever you just
+tried to do.
+
+There are a large number of common (in the sense that "everyone has
+these, really") Unix utilities that are not provided with XEmacs. The
+GNU Project's implementations are available for Windows in the the
+Cygwin distribution (http://www.cygwin.com/), which also provides a
+complete Unix emulation environment (and thus makes ports of Unix
+utilities nearly trivial). Another implementation is that from MinGW
+(http://www.mingw.org/msys.shtml).
+
+*** Weird crashes in pdump load or shortly after pdump load.
+
+This can happen with incremental linking. Check if you have set
+SUPPORT_EDIT_AND_CONTINUE to non-zero in config.inc, which must allow
+incremental linking to be enabled (otherwise it's disabled). Either turn
+this off, execute `nmake -f xemacs.mak clean', or manually remove
+`temacs.exe' and `xemacs.exe'.
+
** Cygwin
-*** In general use etc/check_cygwin_setup.sh to trap environment problems.
-The script etc/check_cygwin_setup.sh will attempt to detect whether
-you have a suitable environment for building. This script may not work
-correctly if you are using ash instead of bash (see below).
+See also Intel Architecture General, above.
-*** X11 not detected.
+*** Signal 11 when building or running a dumped XEmacs.
-This is usually because xmkmf is not in your path or because you are
-using the default cygwin shell. The default cygwin shell (/bin/sh.exe)
-is ash which appears to work in most circumstances but has some weird
-failure modes. I recommend replacing sh.exe with bash.exe, this will
-mean configure is slower but more reliable.
+This appears to happen when using the traditional dumping mechanism and
+the system malloc. Andy Piper writes:
-*** Subprocesses do not work.
+ Traditional dumping on Cygwin relies on using gmalloc (there are specific
+ hacks in our version of gmalloc to support this), I suspect using sysmalloc
+ is the problem.
-You do not have "tty" in your CYGWIN32 (for b19) or CYGWIN (for b20)
-environment variable. This must be set in your autoexec.bat (win95) or
-the system properties (winnt) as it must be read before the cygwin dll
-initializes.
+Try configuring with pdump or without system malloc.
-*** ^G does not work on hung subprocesses.
+*** In general use etc/check_cygwin_setup.sh to trap environment problems.
+
+The script etc/check_cygwin_setup.sh will attempt to detect whether
+you have a suitable environment for building. This script may not work
+correctly if you are using ash instead of bash (see below).
-This is a known problem. It can be remedied with cygwin b20 or greater
-by defining BROKEN_SIGIO in src/s/cygwin32.h, however this currently
-leads to instability in XEmacs.
+*** Syntax errors running configure scripts, make failing with exit code 127
+ in inexplicable situations, etc.
-*** The XEmacs executable crashes at startup.
+[[ This may be because you are using the default Cygwin shell, under old
+versions of Cygwin. The default Cygwin shell (/bin/sh.exe) is ash, which
+appears to work in most circumstances but has some weird failure modes.
+You may need to replace the symlink with bash.exe. ]] This doesn't appear
+to affect Cygwin any longer, and /bin/sh.exe is no longer a symlink in
+any case.
-This can be caused by many things.
+*** Lots of compile errors, esp. on lines containing macro definitions
+ terminated by backslashes.
-If you are running with X11 you need to have cygwin b19 or cygwin
-b20.1 or greater, cygwin b20 will not work.
+Your partition holding the source files is mounted binary. It needs
+to be mounted text. (This will not screw up any binary files because
+the Cygwin utilities specify explicitly whether they want binary or
+text mode when working with source vs. binary files, which overrides
+the mount type.) To fix this, you just need to run the appropriate
+mount command once -- afterwards, the settings are remembered in the
+registry.
-If you are running with cygwin b19 make sure you are using egcs 1.0.2
-rather than vanilla gcc. XEmacs builds by default with -O3 which does
-not work with the gcc that ships with b19. Alternatively use -O2.
+*** Errors from make like /c:not found.
+
+Make sure you set the environment variable MAKE_MODE to UNIX in your
+.bashrc, Control Panel (Windows 2000/NT), or AUTOEXEC.BAT (Windows
+98/95).
*** The info files will not build.
-makeinfo that ships with cygwin (all versions) is a noop. You need to
-obtain makeinfo from somewhere or build it yourself.
+makeinfo that ships with old versions of Cygwin doesn't work.
+Upgrade to the latest Cygwin version.
-*** I have no graphics.
+*** XEmacs hangs while attempting to rebuild the .elc files.
-You need to obtain the various graphics libraries. Pre-built versions
-of these and the X libraries are located on the XEmacs website in
-ftp://ftp.xemacs.org/pub/aux/cygwin*.
+Check to make sure you're not configuring with rel-alloc. The relocating
+allocator does not currently work under Cygwin due to bugs in Cygwin's
+mmap().
-*** There are no images in the toolbar buttons.
+*** Trying to build with X, but X11 not detected.
-You need version 4.71 of commctrl.dll which does not ship with windows
-95. You can get this by installing IE 4.0 or downloading it from the
-microsoft website.
+This is usually because xmkmf is not in your path or because you are
+using the default Cygwin shell. (See above.)
* Problems with running XEmacs
==============================
** General
-*** C-z just refreshes the screen instead of suspending Emacs.
-You are probably using a shell that doesn't support job control, even
-though the system itself is capable of it. Try using a different
-shell.
+*** XEmacs consistently crashes in a particular strange place.
+
+One known case is on Red Hat Linux, compiled with GCC, attempting to
+render PNG images. The problem is that XEmacs code is not compliant
+with ANSI rules about aliasing. Adding -fno-strict-aliasing to CFLAGS
+may help (or the equivalent for your compiler). (Some versions of
+XEmacs may already do this automatically, but if you specify CFLAGS or
+--cflags yourself, you will have to add this flag by hand.)
+
+If you diagnose this bug for some other symptoms or systems, please
+let us know (if you can send mail from the affected system, use M-x
+report-xemacs-bug) so we can update this entry.
+
+*** Changes made to .el files do not take effect.
+
+You may have forgotten to recompile them into .elc files. Then the
+old .elc files will be loaded, and your changes will not be seen. To
+fix this, do `M-x byte-recompile-directory' and specify the directory
+that contains the Lisp files.
+
+Note that you will get a warning when loading a .elc file that is
+older than the corresponding .el file.
+
+*** VM appears to hang in large folders.
+
+This is normal (trust us) when upgrading to VM-6.22 from earlier
+versions. Let VM finish what it is doing and all will be well.
+
+*** Starting with 21.4.x, killing text is absurdly slow.
+
+See FAQ Q3.10.6. Should be available on the web near
+http://www.xemacs.org/faq/xemacs-faq.html#SEC160.
+
+*** Whenever I try to retrieve a remote file, I have problems.
+
+A typical error: FTP Error: USER request failed; 500 AUTH not understood.
+Thanks to giacomo boffi <giacomo.boffi@polimi.it> on comp.emacs.xemacs:
+
+ tell your ftp client to not attempt AUTH authentication (or do not
+ use FTP servers that don't understand AUTH)
+
+and notes that you need to add an element (often "-u") to
+`efs-ftp-program-args'. Use M-x customize-variable, and verify the
+needed flag with `man ftp' or other local documentation.
+
+*** gnuserv is running, some clients can connect, but others cannot.
+
+The code in gnuslib.c respects the value of TMPDIR. If the server and
+the client have different values in their environment, you lose.
+One program known to set TMPDIR and manifest this problem is exmh.
+You can defeat the use of TMPDIR by unsetting USE_TMPDIR at the top of
+gnuserv.h at build time.
+
+** General Unix
*** You type Control-H (Backspace) expecting to delete characters.
(global-set-key "\M-?" 'help-command)
+*** At startup I get a warning on stderr about missing charsets:
+
+ Warning: Missing charsets in String to FontSet conversion
+
+You need to specify appropriate charsets for your locale (usually the
+value of the LANG environment variable) in .Xresources. See
+etc/Emacs.ad for the relevant resources (mostly menubar fonts and
+fontsets). Do not edit this file, it's purely informative.
+
+If you have no satisfactory fonts for iso-8859-1, XEmacs will crash.
+
+It looks like XFree86 4.x (the usual server on Linux and *BSD) has
+some braindamage where .UTF-8 locales will always generate this
+message, because the XFree86 (font)server doesn't know that UTF-8 will
+use the ISO10646-1 font registry (or a Cmap or something).
+
+If you are not using a .UTF-8 locale and see this warning for a
+character set not listed in the default in Emacs.ad, please let
+xemacs-beta@xemacs.org know about it, so we can add fonts to the
+appropriate fontsets and stifle this warning. (Unfortunately it's
+buried in Xlib, so we can't easily get rid of it otherwise.)
+
*** Mail agents (VM, Gnus, rmail) cannot get new mail
rmail and VM get new mail from /usr/spool/mail/$USER using a program
mode of the installed copy; changing the group and mode of the build
directory copy is ineffective.
-*** VM appears to hang in large folders.
-
-This is normal (trust us) when upgrading to VM-6.22 from earlier
-versions. Let VM finish what it is doing and all will be well.
-
-*** Changes made to .el files do not take effect.
-
-You may have forgotten to recompile them into .elc files. Then the
-old .elc files will be loaded, and your changes will not be seen. To
-fix this, do `M-x byte-recompile-directory' and specify the directory
-that contains the Lisp files.
-
-Note that you will get a warning when loading a .elc file that is
-older than the corresponding .el file.
-
*** Things which should be bold or italic (such as the initial
copyright notice) are not.
Try evaluating the form (setq lock-directory nil) and see if that helps.
There is a problem with file-locking on some systems (possibly related
-to NFS) that I don't understand. Please send mail to the address
-xemacs@xemacs.org if you figure this one out.
+to NFS) that I don't understand. Please send mail to the address
+xemacs-beta@xemacs.org if you figure this one out.
*** When emacs starts up, I get lots of warnings about unknown keysyms.
If you are running the prebuilt binaries, the Motif library expects to find
certain thing in the XKeysymDB file. This file is normally in /usr/lib/X11/
or in /usr/openwin/lib/. If you keep yours in a different place, set the
-environment variable $XKEYSYMDB to point to it before starting emacs. If
-you still have the problem after doing that, perhaps your version of X is
+environment variable $XKEYSYMDB to point to it before starting emacs. If
+you still have the problem after doing that, perhaps your version of X is
too old. There is a copy of the MIT X11R5 XKeysymDB file in the emacs `etc'
directory. Try using that one.
*** My X resources used to work, and now some of them are being ignored.
Check the resources in .../etc/Emacs.ad (which is the same as the file
-sample.Xdefaults). Perhaps some of the default resources built in to
+sample.Xresources). Perhaps some of the default resources built in to
emacs are now overriding your existing resources. Copy and edit the
resources in Emacs.ad as necessary.
XEmacs has fairly new TTY redisplay support (beginning from 19.12),
which doesn't include some basic TTY optimizations -- like using
scrolling regions to move around blocks of text. This is why
-redisplay on the traditional terminals, or over slow lines can be very
+redisplay on the traditional terminals, or over slow lines can be very
slow.
If you are interested in fixing this, please let us know at
-<xemacs@xemacs.org>.
+<xemacs-beta@xemacs.org>.
*** Screen is updated wrong, but only on one kind of terminal.
without optimization. If that doesn't work, try recompiling with
SYSTEM_MALLOC defined, and/or with REL_ALLOC undefined.
-*** A position you specified in .Xdefaults is ignored, using twm.
+*** A position you specified in .Xresources is ignored, using twm.
twm normally ignores "program-specified" positions.
You can tell it to obey them with this command in your `.twmrc' file:
if ($?EMACS) then
if ($EMACS == "t") then
- unset edit
+ unset edit
stty -icrnl -onlcr -echo susp ^Z
endif
endif
*** The popup menu appears at the bottom/right of my screen.
-You probably have something like the following in your ~/.Xdefaults
+You probably have something like the following in your ~/.Xresources
Emacs.geometry: 81x56--9--1
Emacs*EmacsFrame.geometry: 81x56--9--1
+*** When I try to use the PostgreSQL functions, I get a message about
+undefined symbols.
+
+The only known case in which this happens is if you are using gcc, you
+configured with --error-checking=all and --with-modules, and you
+compiled with no optimization. If you encounter this problem in any
+other situation, please inform xemacs-beta@xemacs.org.
+
+This problem stems from a gcc bug. With no optimization, functions
+declared `extern inline' sometimes are not completely compiled away. An
+undefined symbol with the function's name is put into the resulting
+object file. In this case, when the postgresql module is loaded, the
+linker is unable to resolve that symbol, so the module load fails. The
+workaround is to recompile the module with optimization turned on. Any
+optimization level, including -Os, appears to work.
+
+*** C-z just refreshes the screen instead of suspending Emacs.
+
+You are probably using a shell that doesn't support job control, even
+though the system itself is capable of it. Try using a different
+shell.
+
+** MacOS/X, Darwin
+*** XEmacs crashes on MacOS within font-lock, or when dealing
+with large compilation buffers, or in other regex applications.
+
+The default stack size under MacOS/X is rather small (512k as opposed
+to Solaris 8M), hosing the regexp code, which uses alloca()
+extensively, overflowing the stack when complex regexps are used.
+Workarounds:
+
+1) Increase your stack size, using `ulimit -s 8192' or a (t)csh
+ equivalent;
+
+2) Recompile regex.c with REGEX_MALLOC defined.
** AIX
*** Your Delete key sends a Backspace to the terminal, using an AIXterm.
-The solution is to include in your .Xdefaults the lines:
+The solution is to include in your .Xresources the lines:
*aixterm.Translations: #override <Key>BackSpace: string(0x7f)
aixterm*ttyModes: erase ^?
** Linux
-*** Mandrake
+*** XEmacs crashes on startup, in make-frame.
-The Mandrake Linux distribution is attempting to comprehensively
-update the user interface, and make it consistent across
-applications. This is very difficult, and will occasionally cause
-conflicts with applications like Emacs with their own long-established
-interfaces. Known issues specific to Mandrake or especially common:
+Typically the Lisp backtrace includes
-Some versions of XEmacs (21.1.9 is known) distributed with Mandrake
-were patched to make the Meta and Alt keysyms synonymous. These
-normally work as expected in the Mandrake environment. However,
-custom-built XEmacsen (including all 21.2 betas) will "inexplicably"
-not respect the "Alt-invokes-Meta-commands" convention. See "I want
-XEmacs to use the Alt key" below.
+ make-frame(nil #<x-device on ":0.0" 0x2558>)
-The color-gcc wrapper (see below) is in common use on the Mandrake
-platform.
+somewhere near the top. The problem is due to an improvement in GNU
+ld that sorts the ELF reloc sections in the executable, giving
+dramatic speedups in startup for large executables. It also confuses
+the traditional unexec code in XEmacs, leading to the core dump. The
+solution is to use the --pdump or --ldflags='-z nocombreloc' options
+to configure. Recent 21.4 and 12.5 autodetect this in configure.
+
+Red Hat and SuSE (at least) distributed a prerelease version of ld
+(versions around 2.11.90.x.y) where autodetection is impossible. The
+recommended procedure is to upgrade to binutils >= 2.12 and rerun
+configure. Otherwise you must apply the flags by hand. --pdump is
+recommended.
*** I want XEmacs to use the Alt key, not the XXX key, for Meta commands
This is written for the mainline GNU Emacs but the author has made
efforts to adapt it to XEmacs. YMMV.
-*** You get crashes in a non-C locale with Linux GNU Libc 2.0.
-
-Internationalization was not the top priority for GNU Libc 2.0.
-As of this writing (1998-12-28) you may get crashes while running
-XEmacs in a non-C locale. For example, `LC_ALL=en_US xemacs' crashes
-while `LC_ALL=C xemacs' runs fine. This happens for example with GNU
-libc 2.0.7. Installing libintl.a and libintl.h built from gettext
-0.10.35 and re-building XEmacs solves the crashes. Presumably soon
-everyone will upgrade to GNU Libc 2.1 and this problem will go away.
-
-*** `C-z', or `M-x suspend-emacs' hangs instead of suspending.
-
-If you build with `gpm' support on Linux, you cannot suspend XEmacs
-because gpm installs a buggy SIGTSTP handler. Either compile with
-`--with-gpm=no', or don't suspend XEmacs on the Linux console until
-this bug is fixed.
-
-*** With certain fonts, when the cursor appears on a character, the
-character doesn't appear--you get a solid box instead.
-
-One user on a Linux system reported that this problem went away with
-installation of a new X server. The failing server was XFree86 3.1.1.
-XFree86 3.1.2 works.
-
*** Slow startup on Linux.
People using systems based on the Linux kernel sometimes report that
Also make sure that the `/etc/host.conf' files contains the following
lines:
- order hosts, bind
+ order hosts, bind
multi on
Any changes, permanent and temporary, to the host name should be
solution above is insufficient, because getaddrinfo() by default tries
to get IPv6 information for localhost. This always involves a dns
lookup to get the CNAME, and the strategies above don't work. It then
-falls back to IPv4 behavior. This is good[tm]; trust us.
+falls back to IPv4 behavior. This is good[tm] according the people at
+WIDE who know about IPv6.
***** Robust network case
If you cannot or do not want to do that, you can hard code IPv4
behavior in src/process-unix.c. This is bad[tm], on your own head be
-it. In the function unix_canonicalize_host_name() about ten lines
-down, change the statement
+it. Use the configure option `--with-ipv6-cname=no'.
- hints.ai_family = AF_UNSPEC;
+*** Mandrake
-to
+The Mandrake Linux distribution is attempting to comprehensively
+update the user interface, and make it consistent across
+applications. This is very difficult, and will occasionally cause
+conflicts with applications like Emacs with their own long-established
+interfaces. Known issues specific to Mandrake or especially common:
- hints.ai_family = PF_INET;
+Some versions of XEmacs (21.1.9 is known) distributed with Mandrake
+were patched to make the Meta and Alt keysyms synonymous. These
+normally work as expected in the Mandrake environment. However,
+custom-built XEmacsen (including all 21.2 betas) will "inexplicably"
+not respect the "Alt-invokes-Meta-commands" convention. See "I want
+XEmacs to use the Alt key" below.
-and rebuild XEmacs.
+The color-gcc wrapper (see below) is in common use on the Mandrake
+platform.
+
+*** You get crashes in a non-C locale with Linux GNU Libc 2.0.
+
+Internationalization was not the top priority for GNU Libc 2.0.
+As of this writing (1998-12-28) you may get crashes while running
+XEmacs in a non-C locale. For example, `LC_ALL=en_US xemacs' crashes
+while `LC_ALL=C xemacs' runs fine. This happens for example with GNU
+libc 2.0.7. Installing libintl.a and libintl.h built from gettext
+0.10.35 and re-building XEmacs solves the crashes. Presumably soon
+everyone will upgrade to GNU Libc 2.1 and this problem will go away.
+
+*** `C-z', or `M-x suspend-emacs' hangs instead of suspending.
+
+If you build with `gpm' support on Linux, you cannot suspend XEmacs
+because gpm installs a buggy SIGTSTP handler. Either compile with
+`--with-gpm=no', or don't suspend XEmacs on the Linux console until
+this bug is fixed.
-getaddrinfo() is also called in src/sysdep.c:init_system_name() and in
-src/process-unix.c:unix_open_network_stream(). It should not be
-useful to make this change in either of those places.
+*** With certain fonts, when the cursor appears on a character, the
+character doesn't appear--you get a solid box instead.
+One user on a Linux system reported that this problem went away with
+installation of a new X server. The failing server was XFree86 3.1.1.
+XFree86 3.1.2 works.
** IRIX
*** On Irix, I don't see the toolbar icons and I'm getting lots of
be set-UID to root, or non-root programs like Emacs will not be able
to allocate ptys reliably.
-*** Motif dialog boxes lose on Irix.
-
-Larry Auton <lda@control.att.com> writes:
-Beware of not specifying
-
- --with-dialogs=athena
-
-if it builds with the motif dialogs [boom!] you're a dead man.
-
*** Beware of the default image & graphics library on Irix
Richard Cognot <cognot@ensg.u-nancy.fr> writes:
** Digital UNIX/OSF/VMS/Ultrix
*** XEmacs crashes on Digital Unix within font-lock, or when dealing
-with large compilation buffers.
+with large compilation buffers, or in other regex applications.
The default stack size under Digital Unix is rather small (2M as
opposed to Solaris 8M), hosing the regexp code, which uses alloca()
The solution is to add a pair of quotes around `tty` to make it a
single word:
-if (`tty` == "/dev/console")
+if (`tty` == "/dev/console")
should be changed to:
-if ("`tty`" == "/dev/console")
+if ("`tty`" == "/dev/console")
Even better, move things that set up terminal sections out of .cshrc
and into .login.
** Windows
-*** Emacs exits with "X protocol error" when run with an X server for
-Windows.
+*** Conflicts with FSF NTEmacs
+
+Depending on how it is installed, FSF NTEmacs may setup various EMACS*
+variables in your environment. The presence of these variables may
+cause XEmacs to fail at startup, cause you to see corrupted
+doc-strings, or cause other random problems.
+
+You should remove these variables from your environment. These
+variables are not required to run FSF NTEmacs if you start it by
+running emacs.bat.
+
+*** XEmacs can't find my init file
+
+XEmacs looks for your init in your "home" directory -- either in
+`~/.xemacs/init.el' or `~/.emacs'. XEmacs decides that your "home"
+directory is, in order of preference:
+
+- The value of the HOME environment variable, if the variable exists.
+- The value of the registry entry SOFTWARE\XEmacs\XEmacs\HOME,
+ if it exists.
+- The value of the HOMEDRIVE and HOMEPATH environment variables, if
+ these variables both exist.
+- C:\.
+
+To determine what XEmacs thinks your home directory is, try opening
+a file in the `~' directory, and you should see its expansion in the
+modeline. If this doesn't work, type ESC : (user-home-directory).
+
+*** XEmacs can't find any packages
+
+XEmacs looks for your packages in subdirectories of a directory which
+is set at compile-time (see `config.inc'), and whose default is
+`C:\Program Files\XEmacs'. XEmacs also looks in `~/.xemacs', where
+`~' refers to your home directory (see previous entry). The variable
+`configure-package-path' holds the actual path that was compiled into
+your copy of XEmacs.
+
+The compile-time default location can be overridden by the EMACSPACKAGEPATH
+environment variable or by the SOFTWARE\XEmacs\XEmacs\EMACSPACKAGEPATH
+registry entry. You should check that these variables, if they exist,
+point to the actual location of your package tree.
+
+*** XEmacs doesn't die when shutting down Windows 95 or 98
+
+When shutting down Windows 95 or 98 you may see a dialog that says
+ "xemacs / You must quit this program before you quit Windows".
+It is safe to
+ "Click OK to quit the program and Windows",
+but you won't be offered a chance to save any modified XEmacs buffers.
+
+*** Key bindings
+
+The C-z, C-x, C-c, and C-v keystrokes have traditional uses in both
+emacs and Windows programs. XEmacs binds these keys to their
+traditional emacs uses, and provides Windows 3.x style bindings for
+the Cut, Copy and Paste functions.
+
+ Function XEmacs binding
+ -------- --------------
+ Undo C-_
+ Cut Sh-Del
+ Copy C-Insert
+ Paste Sh-Insert
+
+You can rebind keys to make XEmacs more Windows-compatible; for
+example, to bind C-z to undo:
+
+ (global-set-key [(control z)] 'undo)
+
+Rebindind C-x and C-c is trickier because by default these are prefix
+keys in XEmacs. See the "Key Bindings" node in the XEmacs manual.
+
+*** Behavior of selected regions
+
+Use the pending-del package to enable the standard Windows behavior of
+self-inserting deletes region.
+
+*** Limitations on the use of the AltGr key.
+
+In some locale and OS combinations you can't generate M-AltGr-key or
+C-M-AltGr-key sequences at all.
+
+To generate C-AltGr-key or C-M-AltGr-key sequences you must use the
+right-hand Control key and you must press it *after* AltGr.
-A certain X server for Windows had a bug which caused this.
-Supposedly the newer 32-bit version of this server doesn't have the
-problem.
+These limitations arise from fundamental problems in the way that the
+win32 API reports AltGr key events. There isn't anything that XEmacs
+can do to work round these problems that it isn't already doing.
+You may want to create alternative bindings if any of the standard
+XEmacs bindings require you to use some combination of Control or Meta
+and AltGr.
+
+*** Limited support for subprocesses under Windows 9x
+
+Attempting to use call-process to run a 16bit program gives a
+"Spawning child process: Exec format error". For example shell-command
+fails under Windows 95 and 98 if you use command.com or any other
+16bit program as your shell.
+
+XEmacs may incorrectly quote your call-process command if it contains
+double quotes, backslashes or spaces.
+
+start-process and functions that rely on it are supported under Windows 95,
+98 and NT. However, starting a 16bit program that requires keyboard input
+may cause XEmacs to hang or crash under Windows 95 and 98, and will leave
+the orphaned 16bit program consuming all available CPU time.
+
+Sending signals to subprocesses started by call-process or by
+start-process fails with a "Cannot send signal to process" error under
+Windows 95 and 98. As a side effect of this, quitting XEmacs while it
+is still running subprocesses causes it to crash under Windows 95 and
+98.
+
+
+** Cygwin
+*** Signal 11 when building or running a dumped XEmacs.
+
+See the section on Cygwin above, under building.
+
+*** XEmacs fails to start because cygXpm-noX4.dll was not found.
+
+Andy Piper <andy@xemacs.org> sez:
+
+ cygXpm-noX4 is part of the cygwin distribution under libraries or
+ graphics, but is not installed by default. You need to run the
+ cygwin setup again and select this package.
+
+*** Subprocesses do not work.
+
+You do not have "tty" in your CYGWIN environment variable. This must
+be set in your autoexec.bat (win95) or the system properties (winnt)
+as it must be read before the cygwin DLL initializes.
+
+*** ^G does not work on hung subprocesses.
+
+This is a known problem. It can be remedied by defining BROKEN_SIGIO
+in src/s/cygwin.h, however this currently leads to instability in XEmacs.
+(#### is this still true?)
+
+*** Errors from make like `/c:not found' when running `M-x compile'.
+
+Make sure you set the environment variable MAKE_MODE to UNIX in your
+init file (.xemacs/init.el), Control Panel (Windows 2000/NT), or
+AUTOEXEC.BAT (Windows 98/95).
+
+*** There are no images in the toolbar buttons.
+
+You need version 4.71 of commctrl.dll which does not ship with windows
+95. You can get this by installing IE 4.0 or downloading it from the
+microsoft website.
* Compatibility problems (with Emacs 18, GNU Emacs, or previous XEmacs/lemacs)
and testers. It probably doesn't work.
** There are no `native XEmacs' TUTORIALs for any Asian languages,
-including Japanese. FSF Emacs and XEmacs tutorials are quite similar,
+including Japanese. FSF Emacs and XEmacs tutorials are quite similar,
so it should be sufficient to skim through the differences and apply
them to the Japanese version.
projects / chise / xemacs-chise.git.1 / blobdiff