diff PROBLEMS @ 412:697ef44129c6 r21-2-14

Import from CVS: tag r21-2-14
author cvs
date Mon, 13 Aug 2007 11:20:41 +0200
parents de805c49cfc1
children 11054d720c21
line wrap: on
line diff
--- a/PROBLEMS	Mon Aug 13 11:19:22 2007 +0200
+++ b/PROBLEMS	Mon Aug 13 11:20:41 2007 +0200
@@ -41,8 +41,8 @@
 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.
 
-*** 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'.
+*** Don't use -O2 with gcc 2.7.2 under Intel/XXX 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
@@ -50,25 +50,6 @@
 
 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 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'.
 
@@ -144,15 +125,9 @@
 ** AIX
 *** 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
-    xemacs -nw to fail in various ways.  The official APAR is this:
-
-APAR NUMBER: <IX89470>            RESOLVED AS: PROGRAM ERROR
-
-ABSTRACT:
-<IX89470>: LIBXT.A INCORRECT HANDLING OF EXCEPTIONS IN XTAPPADDINPUT
-
-    The solution is to install X11.base.lib at version >=4.3.2.5.
+*** The libXt shipped with AIX 4.3 is broken.  This causes xemacs -nw
+    to fail in various ways.  The solution is to build against stock
+    X11R6.
 
 *** On AIX, you get this compiler error message:
 
@@ -400,25 +375,24 @@
 
 *** On HP-UX, problems with make
 
-Marcus Thiessel <marcus@xemacs.org>
+Marcus Thiessel <marcus_thiessel@hp.com>
 
   Some releases of XEmacs (e.g. 20.4) require GNU make to build
   successfully. You don't need GNU make when building 21.x.
 
 *** On HP-UX 9.05 XEmacs won't compile or coredump during the build.
 
-Marcus Thiessel <marcus@xemacs.org>
+Marcus Thiessel <marcus_thiessel@hp.com>
 
   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)
+*** On HP-UX 11.0 XEmacs causes excessive X11 errors when running.
 
-Marcus Thiessel <marcus@xemacs.org>
+Marcus Thiessel <marcus_thiessel@hp.com>
 
-  Unfortunately, XEmacs releases prior to 21.0 don't work with
-  Motif2.1. It will compile but you will get excessive X11 errors like
+  Unfortunately, XEmacs releases <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)
 
@@ -431,19 +405,6 @@
   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:
@@ -581,23 +542,17 @@
 *** You type Control-H (Backspace) expecting to delete characters.
 
 Emacs has traditionally used Control-H for help; unfortunately this
-interferes with its use as Backspace on TTY's.  As of XEmacs 21,
-XEmacs looks at the "erase" setting of TTY structures and maps C-h to
-backspace when erase is set to C-h.  This is sort of a special hack,
-but it makes it possible for you to use the standard:
-
-    stty erase ^H
+interferes with its use as Backspace on TTY's.  One way to solve this
+problem is to put this in your .emacs:
 
-to get your backspace key to erase characters.  The erase setting is
-recorded in the Lisp variable `tty-erase-char', which you can use to
-tune the settings in your .emacs.
+  (when (eq tty-erase-char ?\C-h)
+    (keyboard-translate ?\C-h ?\C-?)
+    (global-set-key "\M-?" 'help-command))
 
-A major drawback of this is that when C-h becomes backspace, it no
-longer invokes help.  In that case, you need to use f1 for help, or
-bind another key.  An example of the latter is the following code,
-which moves help to Meta-? (ESC ?):
+This checks whether the TTY erase char is C-h, and if it is, makes
+Control-H (Backspace) work sensibly, and moves help to Meta-? (ESC ?).
 
-    (global-set-key "\M-?" 'help-command)
+Note that you can probably also access help using F1.
 
 *** Mail agents (VM, Gnus, rmail) cannot get new mail
 
@@ -1458,60 +1413,6 @@
     add mod2 = Mode_switch
     EOF
 
-
-*** XEmacs dumps core at startup when native audio is used.  Native
-audio does not work with recent versions of HP-UX.
-
-Under HP-UX 10.20 and later (e.g., HP-UX 11.XX), with native audio
-enabled, the dumped XEmacs binary ("xemacs") core dumps at startup if
-recent versions of the libAlib.sl audio shared library is used.  Note
-that "temacs" will run, but "xemacs" will dump core.  This, of course,
-causes the XEmacs build to fail.  If GNU malloc is enabled, a stack
-trace will show XEmacs to have crashed in the "first" call to malloc().
-
-This bug currently exists in all versions of XEmacs, when the undump
-mechanism is used.  It is not known if using the experimental portable
-dumper will allow native audio to work.
-
-**** Cause:
-
-Recent versions of the HP-UX 10.20 (and later) audio shared library (in
-/opt/audio/lib), pulls in the libdce shared library, which pulls in a
-thread (libcma) library.  This prevents the HP-UX undump() routine (in
-unexhp9k800.c) from properly working.  What's happening is that some
-initialization routines are being called in the libcma library, *BEFORE*
-main() is called, and these initialization routines are calling
-malloc().  Unfortunately, in order for the undumper to work, XEmacs must
-adjust (move upwards) the sbrk() value *BEFORE* the first call to
-malloc(); if malloc() is called before XEmacs has properly adjusted sbrk
-(which is what is happening), dumped memory that is being used by
-XEmacs, is improperly re-allocated for use by malloc() and the dumped
-memory is corrupted.  This causes XEmacs to die an horrible death.
-
-It is believed that versions of the audio library past December 1998
-will trigger this problem.  Under HP-UX 10.20, you probably have to
-install audio library patches to encounter this.  It's probable that
-recent "fresh, out-of-the-box" HP-UX 11.XX workstations also have this
-problem.  For HP-UX 10.20, it's believed that audio patch PHSS_17121 (or
-a superceeding one, like PHSS_17554, PHSS_17971, PHSS_18777, PHSS_21481,
-or PHSS_21662, etc.) will trigger this.
-
-To check if your audio library will cause problems for XEmacs, run
-"chatr /opt/audio/lib/libAlib.sl".  If "libdce" appears in the displayed
-shared library list, XEmacs will probably encounter problems if audio is
-enabled.
-
-**** Workaround:
-
-Don't enable native audio.  Re-run configure without native audio
-support.
-
-If your site supports it, try using NAS (Network Audio Support).
-
-Try using the experimental portable dumper.  It may work, or it may
-not.
-
-
 *** `Pid xxx killed due to text modification or page I/O error'
 
 On HP-UX, you can get that error when the Emacs executable is on an NFS