This file describes various problems that have been encountered
in compiling, installing and running XEmacs. It has been updated for
-XEmacs 21.0.
+XEmacs 21.4.
This file is rather large, but we have tried to sort the entries by
their respective relevance for XEmacs, but may have not succeeded
===============================
** 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
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 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:
Processing include file ./XMenuInt.h
** SunOS/Solaris
+*** Dumping error when using GNU binutils / GNU ld on a Sun.
+
+Errors similar to the following:
+
+ Dumping under the name xemacs unexec():
+ dldump(/space/rpluim/xemacs-obj/src/xemacs): ld.so.1: ./temacs:
+ fatal: /space/rpluim/xemacs-obj/src/xemacs: unknown dynamic entry:
+ 1879048176
+
+are caused by using GNU ld. There are several workarounds available:
+
+In XEmacs 21.2 or later, configure using the new portable dumper
+(--pdump).
+
+Alternatively, you can link using the Sun version of ld, which is
+normally held in /usr/ccs/bin. This can be done by one of:
+
+- building gcc with these configure flags:
+ configure --with-ld=/usr/ccs/bin/ld --with-as=/usr/ccs/bin/as
+
+- adding -B/usr/ccs/bin/ to CFLAGS used to configure XEmacs
+ (Note: The trailing '/' there is significant.)
+
+- uninstalling GNU ld.
+
+The Solaris2 FAQ claims:
+
+ When you install gcc, don't make the mistake of installing
+ GNU binutils or GNU libc, they are not as capable as their
+ counterparts you get with Solaris 2.x.
+
*** Link failure when using acc on a Sun.
To use acc, you need additional options just before the libraries, such as
There have been reports of Sun sed truncating very lines in the
Makefile during configuration. The workaround is to use GNU sed or,
-even better, think of a better way to generate Makefile, and send us a
+even better, think of a better way to generate Makefile, and send us a
patch. :-)
*** On Solaris 2 I get undefined symbols from libcurses.a.
bash, as a workaround.
*** On SunOS, you get linker errors
- ld: Undefined symbol
+ ld: Undefined symbol
_get_wmShellWidgetClass
_get_applicationShellWidgetClass
*** On a Sun running SunOS 4.1.1, you get this error message from GNU ld:
- /lib/libc.a(_Q_sub.o): Undefined symbol __Q_get_rp_rd referenced from text segment
+ /lib/libc.a(_Q_sub.o): Undefined symbol __Q_get_rp_rd referenced from text segment
The problem is in the Sun shared C library, not in GNU ld.
*** SunOS 4.1.2: undefined symbol _get_wmShellWidgetClass
Apparently the version of libXmu.so.a that Sun ships is hosed: it's missing
- some stuff that is in libXmu.a (the static version). Sun has a patch for
+ some stuff that is in libXmu.a (the static version). Sun has a patch for
this, but a workaround is to use the static version of libXmu, by changing
the link command from "-lXmu" to "-Bstatic -lXmu -Bdynamic". If you have
OpenWindows 3.0, ask Sun for these patches:
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:
1. The ld in IRIX 5.3 ignores all but the last -rpath
spec, so the patched configure spits out a warning
if --x-libraries or --site-runtime-libraries are
- specified under irix 5.x, and it only adds -rpath
+ specified under irix 5.x, and it only adds -rpath
entries for the --site-runtime-libraries. This bug was
fixed sometime between 5.3 and 6.2.
*** 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.
+ (also appears on AIX as reported in comp.emacs.xemacs)
-Marcus Thiessel <marcus_thiessel@hp.com>
+Marcus Thiessel <marcus@xemacs.org>
- 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)
configure:
--x-libraries="/usr/lib/Motif1.2_R6 -L/usr/lib/X11R6"
-
+
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:
-Unlike XEmacs 19.13, building with the native cc on SCO OpenServer 5
+Unlike XEmacs 19.13, building with the native cc on SCO OpenServer 5
now produces a functional binary. I will typically build this
configuration for COFF with:
--site-includes=/usr/local/include --site-libraries=/usr/local/lib \
--with-xpm --with-xface --with-sound=nas
-This version now supports ELF builds. I highly recommend this to
-reduce the in-core footprint of XEmacs. This is now how I compile
+This version now supports ELF builds. I highly recommend this to
+reduce the in-core footprint of XEmacs. This is now how I compile
all my test releases. Build it like this:
/path_to_XEmacs_source/configure --with-gcc=no \
--site-includes=/usr/local/include --site-libraries=/usr/local/lib \
--with-xpm --with-xface --with-sound=nas --dynamic
-The compiler known as icc [ supplied with the OpenServer 5 Development
+The compiler known as icc [ supplied with the OpenServer 5 Development
System ] generates a working binary, but it takes forever to generate
XEmacs. ICC also whines more about the code than /bin/cc does. I do
believe all its whining is legitimate, however. Note that you do
--site-includes=/usr/local/include --site-libraries=/usr/local/lib \
--with-xpm --with-xface --with-sound=nas --dynamic --compiler="icc"
-NOTE I have the xpm, xface, and audio libraries and includes in
+NOTE I have the xpm, xface, and audio libraries and includes in
/usr/local/lib, /usr/local/include. If you don't have these,
don't include the "--with-*" arguments in any of my examples.
-In previous versions of XEmacs, you had to override the defaults while
+In previous versions of XEmacs, you had to override the defaults while
compiling font-lock.o and extents.o when building with icc. This seems
to no longer be true, but I'm including this old information in case it
resurfaces. The process I used was:
- make -k
- [ procure pizza, beer, repeat ]
+ make -k
+ [ procure pizza, beer, repeat ]
cd src
make CC="icc -W0,-mP1COPT_max_tree_size=3000" font-lock.o extents.o
make LD=icc
-If you want sound support, get the tls566 supplement from
-ftp.sco.com:/TLS or any of its mirrors. It works just groovy
+If you want sound support, get the tls566 supplement from
+ftp.sco.com:/TLS or any of its mirrors. It works just groovy
with XEmacs.
The M-x manual-entry is known not to work. If you know Lisp and would
like help in making it work, e-mail me at <robertl@dgii.com>.
(UNCHECKED for 19.15 -- it might work).
-In earlier releases, gnuserv/gnuclient/gnudoit would open a frame
+In earlier releases, gnuserv/gnuclient/gnudoit would open a frame
just fine, but the client would lock up and the server would
-terminate when you used C-x # to close the frame. This is now
+terminate when you used C-x # to close the frame. This is now
fixed in XEmacs.
In etc/ there are two files of note. emacskeys.sco and emacsstrs.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
==============================
** General
+*** gnuserv is running, some clients can connect, but others cannot.
+
+The code in gnuslib.c respects the value of TMPDIR. If the server and
+the client have different values in their environment, you lose.
+One program known to set TMPDIR and manifest this problem is exmh.
+You can defeat the use of TMPDIR by unsetting USE_TMPDIR at the top of
+gnuserv.h at build time.
+
*** C-z just refreshes the screen instead of suspending Emacs.
You are probably using a shell that doesn't support job control, even
*** 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
Try evaluating the form (setq lock-directory nil) and see if that helps.
There is a problem with file-locking on some systems (possibly related
-to NFS) that I don't understand. Please send mail to the address
+to NFS) that I don't understand. Please send mail to the address
xemacs@xemacs.org if you figure this one out.
*** When emacs starts up, I get lots of warnings about unknown keysyms.
If you are running the prebuilt binaries, the Motif library expects to find
certain thing in the XKeysymDB file. This file is normally in /usr/lib/X11/
or in /usr/openwin/lib/. If you keep yours in a different place, set the
-environment variable $XKEYSYMDB to point to it before starting emacs. If
-you still have the problem after doing that, perhaps your version of X is
+environment variable $XKEYSYMDB to point to it before starting emacs. If
+you still have the problem after doing that, perhaps your version of X is
too old. There is a copy of the MIT X11R5 XKeysymDB file in the emacs `etc'
directory. Try using that one.
*** My X resources used to work, and now some of them are being ignored.
Check the resources in .../etc/Emacs.ad (which is the same as the file
-sample.Xdefaults). Perhaps some of the default resources built in to
+sample.Xdefaults). Perhaps some of the default resources built in to
emacs are now overriding your existing resources. Copy and edit the
resources in Emacs.ad as necessary.
XEmacs has fairly new TTY redisplay support (beginning from 19.12),
which doesn't include some basic TTY optimizations -- like using
scrolling regions to move around blocks of text. This is why
-redisplay on the traditional terminals, or over slow lines can be very
+redisplay on the traditional terminals, or over slow lines can be very
slow.
If you are interested in fixing this, please let us know at
if ($?EMACS) then
if ($EMACS == "t") then
- unset edit
+ unset edit
stty -icrnl -onlcr -echo susp ^Z
endif
endif
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.
XEmacs in a non-C locale. For example, `LC_ALL=en_US xemacs' crashes
while `LC_ALL=C xemacs' runs fine. This happens for example with GNU
libc 2.0.7. Installing libintl.a and libintl.h built from gettext
-0.10.35 and re-building XEmacs solves the crashes. Presumably soon
+0.10.35 and re-building XEmacs solves the crashes. Presumably soon
everyone will upgrade to GNU Libc 2.1 and this problem will go away.
*** `C-z', or `M-x suspend-emacs' hangs instead of suspending.
*** 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.
-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.
+**** Old problem: IPv4 host lookup
+
+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
Also make sure that the `/etc/host.conf' files contains the following
lines:
- order hosts, bind
+ order hosts, bind
multi on
Any changes, permanent and temporary, to the host name should be
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
The solution is to add a pair of quotes around `tty` to make it a
single word:
-if (`tty` == "/dev/console")
+if (`tty` == "/dev/console")
should be changed to:
-if ("`tty`" == "/dev/console")
+if ("`tty`" == "/dev/console")
Even better, move things that set up terminal sections out of .cshrc
and into .login.
and testers. It probably doesn't work.
** There are no `native XEmacs' TUTORIALs for any Asian languages,
-including Japanese. FSF Emacs and XEmacs tutorials are quite similar,
+including Japanese. FSF Emacs and XEmacs tutorials are quite similar,
so it should be sufficient to skim through the differences and apply
them to the Japanese version.
projects / chise / xemacs-chise.git.1 / blobdiff