+*** XEmacs crashes on exit.
+
+This is known to happen with Lesstif version 0.93.36. It is
+apparently due to breakage in Lesstif. There is a patch for Lesstif.
+
+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 startup, in make-frame.
+
+Typically the Lisp backtrace includes
+
+ make-frame(nil #<x-device on ":0.0" 0x2558>)
+
+somewhere near the top. One 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 either the `--ldflags="-z nocombreloc" or the
+"--pdump" option to configure. "--pdump" is recommended.
+
+Recent 21.4 and 21.5 versions of XEmacs autodetect this feature of ld
+in configure. Unfortunately, Red Hat and SuSE (at least) distributed
+prerelease versions of ld (numbered around 2.11.90.x.y, nicknamed
+"Hannibal Lecter" at XEmacs.ORG) where autodetection fails but the
+feature is enabled by default. The recommended procedure is to
+upgrade to binutils >= 2.12 and rerun configure. Otherwise you must
+apply the flags by hand.
+
+Andrew Jaffe reported a problem on Red Hat 7.3 with identical
+symptoms, except that ld was already being invoked with -z
+nocombreloc. Switching dialogs and widgets from Motif to Athena
+eliminated the problem. Both LessTif and OpenMotif were installed,
+and a bad interaction is suspected. This problem has not yet been
+fully analyzed.
+
+*** Debian
+**** XEmacs warns "Symbol `toggleClassRec' has different size in shared
+ object, consider re-linking / Symbol `labelClassRec' has different
+ size in shared object, consider re-linking / Warning: Representation
+ size 4 must match superclass's to override value"
+
+Sometimes this results in segfaults when using the tab control widget
+or a progress bar widget.
+
+Some versions of Debian install 3D versions of the Athena widget
+library as /usr/X11R6/lib/libXaw.so. We have not yet solved the
+problem of identifying the actual library in use in ./configure, so it
+is possible for XEmacs to be compiled with reference to headers for
+"flat" Xaw but find a "3D" Xaw when loading.
+
+The straightforward solution is to rebuild XEmacs with additional
+configure options: --with-widgets=athena --with-athena=3d.
+
+There are several 3D Athena widget sets available; to see which ones
+are supported by XEmacs, use ./configure --usage.
+
+*** Mandrake
+
+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:
+
+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.
+
+The color-gcc wrapper (see below) is in common use on the Mandrake
+platform.
+
+*** XEmacs configured with ESD crashes with a segmentation violation
+
+This often occurs when a progress bar pops up.