X-Git-Url: http://git.chise.org/gitweb/?p=chise%2Fxemacs-chise.git.1;a=blobdiff_plain;f=PROBLEMS;h=4c5d43d2ce0ada4a1fd5155d20631235c3dd7f8c;hp=448cc366089f4bc4938b86bac4435bffa67a9e8e;hb=0c693dc08f0794304711787b2eb47c144ea4bef1;hpb=5625b2eceaf697f104b5f883ffa73dca6e8fc005 diff --git a/PROBLEMS b/PROBLEMS index 448cc36..4c5d43d 100644 --- a/PROBLEMS +++ b/PROBLEMS @@ -30,13 +30,19 @@ A general advice: =============================== ** 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. + *** egcs-1.1 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 with gcc 2.7.2 under Intel/XXX without also using -`-fno-strength-reduce'. +*** 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 @@ -44,6 +50,25 @@ 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 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'. @@ -119,6 +144,16 @@ libz.a in the X11 binary directory. ** 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: RESOLVED AS: PROGRAM ERROR + +ABSTRACT: +: LIBXT.A INCORRECT HANDLING OF EXCEPTIONS IN XTAPPADDINPUT + + The solution is to install X11.base.lib at version >=4.3.2.5. + *** On AIX, you get this compiler error message: Processing include file ./XMenuInt.h @@ -263,6 +298,14 @@ This is a Linux problem where you've compiled the XEmacs binary on a libc an earlier version. The solution is to upgrade your old library. ** IRIX + +*** 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 writes: @@ -365,24 +408,25 @@ Richard Cognot writes: *** On HP-UX, problems with make -Marcus Thiessel +Marcus Thiessel 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 Thiessel 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. +*** 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 Thiessel - Unfortunately, XEmacs releases <21.0 don't work with Motif2.1. It - will compile but you will get excessive X11 errors like + 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) @@ -395,6 +439,19 @@ Marcus Thiessel 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 + + 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 says: @@ -463,6 +520,61 @@ to take advantage of the keyboard map in emacskeys.sco. Note: Much of the above entry is probably not valid for XEmacs 21.0 and later. +** 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). + +*** X11 not detected. + +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. + +*** Subprocesses do not work. + +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. + +*** ^G does not work on hung subprocesses. + +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. + +*** The XEmacs executable crashes at startup. + +This can be caused by many things. + +If you are running with X11 you need to have cygwin b19 or cygwin +b20.1 or greater, cygwin b20 will not work. + +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. + +*** 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. + +*** I have no graphics. + +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*. + +*** 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. * Problems with running XEmacs @@ -477,17 +589,23 @@ shell. *** 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. One way to solve this -problem is to put this in your .emacs: +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 - (when (eq tty-erase-char ?\C-h) - (keyboard-translate ?\C-h ?\C-?) - (global-set-key "\M-?" 'help-command)) +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. -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 ?). +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 ?): -Note that you can probably also access help using F1. + (global-set-key "\M-?" 'help-command) *** Mail agents (VM, Gnus, rmail) cannot get new mail @@ -935,7 +1053,7 @@ it only if it is undefined. Or you could set TERMCAP only when you set TERM--which should not happen in a non-login shell. -*** The popup menu appears at the buttom/right of my screen. +*** The popup menu appears at the bottom/right of my screen. You probably have something like the following in your ~/.Xdefaults @@ -1148,6 +1266,66 @@ affected virtually all ioctl() calls. ** Linux +*** 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. + +*** I want XEmacs to use the Alt key, not the XXX key, for Meta commands + +For historical reasons, XEmacs looks for a Meta key, then an Alt key. +It binds Meta commands to the X11 modifier bit attached to the first +of these it finds. On PCs, the Windows key is often assigned the Meta +bit, but many desktop environments go to great lengths to get all apps +to use the Alt key, and reserve the Windows key to (sensibly enough) +the window manager. + +One correct way to implement this was suggested on comp.emacs.xemacs +(by Kilian Foth and in more detail by Michael Piotrowski): unmap the +Meta modifier using xmodmap or xkb, and then map the Meta/Windows key +to the Super or Hyper keysym and an appropriate mod bit. XEmacs will +not find the Meta keysym, and default to using the Alt key for Meta +keybindings. Typically few applications use the (X11) Meta modifier; +it is tedious but not too much so to teach the ones you need to use +Super instead of Meta. There may be further useful hints in the +discussion of keymapping on non-Linux platforms. + +*** The color-gcc wrapper + +This wrapper colorizes the error messages from gcc. By default XEmacs +does not interpret the escape sequences used to generate colors, +resulting in a cluttered, hard-to-read buffer. You can remove the +wrapper, or defeat the wrapper colorization in Emacs process buffers +by editing the "nocolor" attribute in /etc/colorgccrc: + +$ diff -u /etc/colorgccrc.old /etc/colorgccrc +--- /etc/colorgccrc.old Tue Dec 26 02:17:46 2000 ++++ /etc/colorgccrc Tue Dec 26 02:15:48 2000 +@@ -34,1 +34,1 @@ +-nocolor: dumb ++nocolor: dumb emacs + +If you want colorization in your Emacs buffers, you may get good +results from the ansi-color.el library: + +http://www.geocities.com/kensanata/color-emacs.html#ansicolors + +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. @@ -1175,16 +1353,20 @@ XFree86 3.1.2 works. *** Slow startup on Linux. People using systems based on the Linux kernel sometimes report that -startup takes 10 to 15 seconds longer than `usual'. +startup takes 10 to 15 seconds longer than `usual'. There are two +problems, one older, one newer. + +**** Old problem: IPv4 host lookup -This is because Emacs looks up the host name when it starts. -Normally, this takes negligible time; the extra delay is due to -improper system configuration. This problem can occur for both -networked and non-networked machines. +On older systems, this is because Emacs looks up the host name when it +starts. Normally, this takes negligible time; the extra delay is due +to improper system configuration. (Recent Linux distros usually have +this configuration correct "out of the box".) This problem can occur +for both networked and non-networked machines. Here is how to fix the configuration. It requires being root. -**** Networked Case +***** Networked Case First, make sure the files `/etc/hosts' and `/etc/host.conf' both exist. The first line in the `/etc/hosts' file should look like this @@ -1203,7 +1385,7 @@ indicated in the `/etc/hosts' file, since it acts a limited local database of addresses and names (e.g., some SLIP connections dynamically allocate ip addresses). -**** Non-Networked Case +***** Non-Networked Case The solution described in the networked case applies here as well. However, if you never intend to network your machine, you can use a @@ -1211,6 +1393,45 @@ simpler solution: create an empty `/etc/host.conf' file. The command `touch /etc/host.conf' suffices to create the file. The `/etc/hosts' file is not necessary with this approach. +**** New problem: IPv6 CNAME lookup + +A newer problem is due to XEmacs changing to use the modern +getaddrinfo() interface from the older gethostbyname() interface. The +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. + +***** Robust network case + +Configure your network so that there are no nameservers configured +until the network is actually running. getaddrinfo() will not try to +access a nameserver that isn't configured. + +***** Flaky network case + +If you have a flaky modem or DSL connection that can be relied on only +to go down whenever you want to bring XEmacs up, you need to force +IPv4 behavior. Explicitly setting DISPLAY=127.0.0.1:0.0 (or whatever +is appropriate) works in most cases. + +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 + + hints.ai_family = AF_UNSPEC; + +to + + hints.ai_family = PF_INET; + +and rebuild XEmacs. + +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. + ** IRIX *** On Irix, I don't see the toolbar icons and I'm getting lots of @@ -1317,7 +1538,7 @@ Richard Cognot writes: launched. Forcing a static link of libc.a alone by adding /usr/lib/libc.a at the end of the link line solves this. Note that my 9.07 build of 19.14b17 and my (old) build of 19.13 both exhibit - the same behaviour. I've tried various hpux patches to no avail. If + the same behavior. I've tried various hpux patches to no avail. If this problem cannot be solved before the release date, binary kits for HP *must* be linked statically against libc, otherwise this problem will show up. (This is directed at whoever will volunteer @@ -1348,6 +1569,60 @@ configures the X server. 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