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
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'.
** AIX
*** On AIX 4.3, you must specify --with-dialogs=athena with configure
-*** 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.
+*** 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.
*** On AIX, you get this compiler error message:
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 <dkindred@cmu.edu> writes:
*** On HP-UX, problems with make
-Marcus Thiessel <marcus_thiessel@hp.com>
+Marcus Thiessel <marcus@xemacs.org>
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@hp.com>
+Marcus Thiessel <marcus@xemacs.org>
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@hp.com>
+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
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:
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 wierd
+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.
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
** 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.
*** 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
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
`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
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
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
projects / chise / xemacs-chise.git.1 / blobdiff