Mercurial > hg > xemacs-beta
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