Known Problems with GNU Emacs
Copyright (C) 1987, 1988, 1989, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
- 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008
+ 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011
Free Software Foundation, Inc.
See the end of the file for license conditions.
This file describes various problems that have been encountered
-in compiling, installing and running GNU Emacs. Try doing Ctl-C Ctl-t
-and browsing through the outline headers.
+in compiling, installing and running GNU Emacs. Try doing C-c C-t
+and browsing through the outline headers. (See C-h m for help on
+Outline mode.) Information about systems that are no longer supported,
+and old Emacs releases, has been removed. Consult older versions of
+this file if you are interested in that information.
* Mule-UCS doesn't work in Emacs 23.
Similarly, any other .el file for which there's no corresponding .elc
file could fail to load if it is compressed.
-The solution is to uncompress all .el files which don't have a .elc
-file.
+The solution is to uncompress all .el files that don't have a .elc file.
Another possible reason for such failures is stale *.elc files
-lurking somewhere on your load-path. The following command will
-print any duplicate Lisp files that are present in load-path:
-
- emacs -q -batch -f list-load-path-shadows
-
-If this command prints any file names, some of these files are stale,
-and should be deleted or their directories removed from your
-load-path.
+lurking somewhere on your load-path -- see the next section.
** Emacs prints an error at startup after upgrading from an earlier version.
The following command will print any duplicate Lisp files that are
present in load-path:
- emacs -q -batch -f list-load-path-shadows
+ emacs -batch -f list-load-path-shadows
If this command prints any file names, some of these files are stale,
and should be deleted or their directories removed from your
+/* $TOG: imInt.c /main/5 1998/05/30 21:11:16 kaleb $ */
/******************************************************************
- Copyright 1992, 1993, 1994 by FUJITSU LIMITED
+ Copyright 1992, 1993, 1994 by FUJITSU LIMITED
@@ -166,8 +166,8 @@
_XimMakeImName(lcd)
- XLCd lcd;
+ XLCd lcd;
{
- char* begin;
- char* end;
+ char* begin = NULL;
+ char* end = NULL;
- char* ret;
- int i = 0;
- char* ximmodifier = XIMMODIFIER;
+ char* ret;
+ int i = 0;
+ char* ximmodifier = XIMMODIFIER;
@@ -182,7 +182,11 @@
- }
- ret = Xmalloc(end - begin + 2);
- if (ret != NULL) {
- - (void)strncpy(ret, begin, end - begin + 1);
+ }
+ ret = Xmalloc(end - begin + 2);
+ if (ret != NULL) {
+ - (void)strncpy(ret, begin, end - begin + 1);
+ if (begin != NULL) {
- + (void)strncpy(ret, begin, end - begin + 1);
+ + (void)strncpy(ret, begin, end - begin + 1);
+ } else {
- + ret[0] = '\0';
+ + ret[0] = '\0';
+ }
- ret[end - begin + 1] = '\0';
- }
- return ret;
+ ret[end - begin + 1] = '\0';
+ }
+ return ret;
** Emacs crashes on startup after a glibc upgrade.
* Crash bugs
+** Emacs crashes when running in a terminal, if compiled with GCC 4.5.0
+This version of GCC is buggy: see
+
+ http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6031
+ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43904
+
+You can work around this error in gcc-4.5 by omitting sibling call
+optimization. To do this, configure Emacs with
+
+ CFLAGS="-g -O2 -fno-optimize-sibling-calls" ./configure
+
** Emacs crashes in x-popup-dialog.
This can happen if the dialog widget cannot find the font it wants to
problem, you should look for a way to configure Emacs so that it uses
terminfo when built.
-** Emacs crashes when using the Exceed 6.0 X server.
+** Emacs crashes when using some version of the Exceed X server.
-If you are using Exceed 6.1, upgrade to a later version. This was
-reported to prevent the crashes.
+Upgrading to a newer version of Exceed has been reported to prevent
+these crashes. You should consider switching to a free X server, such
+as Xming or Cygwin/X.
** Emacs crashes with SIGSEGV in XtInitializeWidgetClass.
On platforms such as Solaris, you can also work around this problem by
configuring your compiler to use the native linker instead of GNU ld.
-** Emacs compiled with Gtk+ crashes when closing a display (x-close-connection).
-
-This happens because of bugs in Gtk+. Gtk+ 2.10 seems to be OK. See bug
-http://bugzilla.gnome.org/show_bug.cgi?id=85715.
+** When Emacs is compiled with Gtk+, closing a display kills Emacs.
-** Emacs compiled with Gtk+ crashes on startup on Cygwin.
+There is a long-standing bug in GTK that prevents it from recovering
+from disconnects: http://bugzilla.gnome.org/show_bug.cgi?id=85715.
-A typical error message is
- ***MEMORY-ERROR***: emacs[5172]: GSlice: failed to allocate 504 bytes
- (alignment: 512): Function not implemented
+Thus, for instance, when Emacs is run as a server on a text terminal,
+and an X frame is created, and the X server for that frame crashes or
+exits unexpectedly, Emacs must exit to prevent a GTK error that would
+result in an endless loop.
-Emacs supplies its own malloc, but glib (part of Gtk+) calls memalign and on
-Cygwin, that becomes the Cygwin supplied memalign. As malloc is not the
-Cygwin malloc, the Cygwin memalign always returns ENOSYS. A fix for this
-problem would be welcome.
+If you need Emacs to be able to recover from closing displays, compile
+it with the Lucid toolkit instead of GTK.
* General runtime problems
These control the actions of Emacs.
~/.emacs is your Emacs init file.
-EMACSLOADPATH overrides which directories the function
-"load" will search.
+EMACSLOADPATH overrides which directories the function "load" will search.
If you observe strange problems, check for these and get rid
of them, then try again.
`mail'. To do this, use the following commands (as root) after doing the
make install.
- chgrp mail movemail
- chmod 2755 movemail
+ chgrp mail movemail
+ chmod 2755 movemail
Installation normally copies movemail from the build directory to an
installation directory which is usually under /usr/local/lib. The
You need to configure your machine with a fully qualified domain name,
(i.e. a name with at least one ".") either in /etc/hosts,
-/etc/hostname, the NIS, or wherever your system calls for specifying
-this.
+/etc/hostname, the NIS, or wherever your system calls for specifying this.
If you cannot fix the configuration, you can set the Lisp variable
mail-host-address to the value you want.
--- serversyscall.c Wed Jan 28 15:14:48 1987
***************
*** 163,169 ****
- /*
- * No return sent for close or fsync!
- */
+ /*
+ * No return sent for close or fsync!
+ */
! if (syscall == RSYS_close || syscall == RSYS_fsync)
- proc->p_returnval = deallocate_fd(proc, msg->m_args[0]);
- else
- {
+ proc->p_returnval = deallocate_fd(proc, msg->m_args[0]);
+ else
+ {
--- 166,172 ----
- /*
- * No return sent for close or fsync!
- */
+ /*
+ * No return sent for close or fsync!
+ */
! if (syscall == RSYS_close)
- proc->p_returnval = deallocate_fd(proc, msg->m_args[0]);
- else
- {
-
-** PSGML
-
-*** Old versions of the PSGML package use the obsolete variables
-`before-change-function' and `after-change-function', which are no
-longer used by Emacs. Please use PSGML 1.2.3 or later.
+ proc->p_returnval = deallocate_fd(proc, msg->m_args[0]);
+ else
+ {
-*** PSGML conflicts with sgml-mode.
+** PSGML conflicts with sgml-mode.
PSGML package uses the same names of some variables (like keymap)
as built-in sgml-mode.el because it was created as a replacement
(from sgml-mode.el) is used for HTML file and loading of psgml.el
(for sgml-mode or xml-mode) will cause an error.
-*** Versions of the PSGML package earlier than 1.0.3 (stable) or 1.1.2
-(alpha) fail to parse DTD files correctly in Emacs 20.3 and later.
-Here is a patch for psgml-parse.el from PSGML 1.0.1 and, probably,
-earlier versions.
-
---- psgml-parse.el 1998/08/21 19:18:18 1.1
-+++ psgml-parse.el 1998/08/21 19:20:00
-@@ -2383,7 +2383,7 @@ (defun sgml-push-to-entity (entity &opti
- (setq sgml-buffer-parse-state nil))
- (cond
- ((stringp entity) ; a file name
-- (save-excursion (insert-file-contents entity))
-+ (insert-file-contents entity)
- (setq default-directory (file-name-directory entity)))
- ((consp (sgml-entity-text entity)) ; external id?
- (let* ((extid (sgml-entity-text entity))
-
-** AUCTeX
-
-You should not be using a version older than 11.52 if you can avoid
-it.
-
-*** Emacs 21 freezes when visiting a TeX file with AUCTeX installed.
-
-Emacs 21 needs version 10 or later of AUCTeX; upgrading should solve
-these problems.
-
-*** No colors in AUCTeX with Emacs 21.
-
-Upgrade to AUC TeX version 10 or later, and make sure it is
-byte-compiled with Emacs 21.
-
** PCL-CVS
*** Lines are not updated or new lines are added in the buffer upon commit.
The cause of this is a shell startup file that sets the TERMCAP
environment variable. The terminal emulator uses that variable to
-provide the information on the special terminal type that Emacs
-emulates.
+provide the information on the special terminal type that Emacs emulates.
Rewrite your shell startup file so that it does not change TERMCAP
in such a case. You could use the following conditional which sets
invoking `df'; (b) use `df' from the GNU Fileutils package; or
(c) use CVS, which is Free Software, instead of ClearCase.
-*** Versions of the W3 package released before Emacs 21.1 don't run
-under Emacs 21. This fixed in W3 version 4.0pre.47.
-
-*** The LDAP support rely on ldapsearch program from OpenLDAP version 2.
-
-It can fail to work with ldapsearch program from OpenLDAP version 1.
-Version 1 of OpenLDAP is now deprecated. If you are still using it,
-please upgrade to version 2. As a temporary workaround, remove
-argument "-x" from the variable `ldap-ldapsearch-args'.
-
*** ps-print commands fail to find prologue files ps-prin*.ps.
This can happen if you use an old version of X-Symbol package: it
* Runtime problems related to font handling
-** Under X11, some characters appear as hollow boxes.
+** Characters are displayed as empty boxes or with wrong font under X.
+
+*** This can occur when two different versions of FontConfig are used.
+For example, XFree86 4.3.0 has one version and Gnome usually comes
+with a newer version. Emacs compiled with Gtk+ will then use the
+newer version. In most cases the problem can be temporarily fixed by
+stopping the application that has the error (it can be Emacs or any
+other application), removing ~/.fonts.cache-1, and then start the
+application again. If removing ~/.fonts.cache-1 and restarting
+doesn't help, the application with problem must be recompiled with the
+same version of FontConfig as the rest of the system uses. For KDE,
+it is sufficient to recompile Qt.
+
+*** Some fonts have a missing glyph and no default character. This is
+known to occur for character number 160 (no-break space) in some
+fonts, such as Lucida but Emacs sets the display table for the unibyte
+and Latin-1 version of this character to display a space.
+
+*** Some of the fonts called for in your fontset may not exist on your
+X server.
Each X11 font covers just a fraction of the characters that Emacs
supports. To display the whole range of Emacs characters requires
-many different fonts, collected into a fontset.
-
-If some of the fonts called for in your fontset do not exist on your X
-server, then the characters that have no font appear as hollow boxes.
-You can remedy the problem by installing additional fonts.
+many different fonts, collected into a fontset. You can remedy the
+problem by installing additional fonts.
The intlfonts distribution includes a full spectrum of fonts that can
display all the characters Emacs supports. The etl-unicode collection
fonts that can display many Unicode characters; they can also be used
by ps-print and ps-mule to print Unicode characters.
-Another cause of this for specific characters is fonts which have a
-missing glyph and no default character. This is known to occur for
-character number 160 (no-break space) in some fonts, such as Lucida
-but Emacs sets the display table for the unibyte and Latin-1 version
-of this character to display a space.
-
** Under X11, some characters appear improperly aligned in their lines.
You may have bad X11 fonts; try installing the intlfonts distribution
-or the etl-unicode collection (see the previous entry).
+or the etl-unicode collection (see above).
+
+** Under X, an unexpected monospace font is used as the default font.
+
+When compiled with XFT, Emacs tries to use a default font named
+"monospace". This is a "virtual font", which the operating system
+(Fontconfig) redirects to a suitable font such as DejaVu Sans Mono.
+On some systems, there exists a font that is actually named Monospace,
+which takes over the virtual font. This is considered an operating
+system bug; see
-** Certain fonts make each line take one pixel more than it "should".
+http://lists.gnu.org/archive/html/emacs-devel/2008-10/msg00696.html
-This is because these fonts contain characters a little taller
-than the font's nominal height. Emacs needs to make sure that
-lines do not overlap.
+If you encounter this problem, set the default font to a specific font
+in your .Xresources or initialization file. For instance, you can put
+the following in your .Xresources:
+
+Emacs.font: DejaVu Sans Mono 12
+
+** Certain fonts make each line take one pixel more than it should.
+
+This is because these fonts contain characters a little taller than
+the font's nominal height. Emacs needs to make sure that lines do not
+overlap.
** Loading fonts is very slow.
away with installation of a new X server. The failing server was
XFree86 3.1.1. XFree86 3.1.2 works.
-** Characters are displayed as empty boxes or with wrong font under X.
-
-This can occur when two different versions of FontConfig are used.
-For example, XFree86 4.3.0 has one version and Gnome usually comes
-with a newer version. Emacs compiled with Gtk+ will then use
-the newer version. In most cases the problem can be temporarily
-fixed by stopping the application that has the error (it can be
-Emacs or any other application), removing ~/.fonts.cache-1,
-and then start the application again.
-If removing ~/.fonts.cache-1 and restarting doesn't help, the
-application with problem must be recompiled with the same version
-of FontConfig as the rest of the system uses. For KDE, it is
-sufficient to recompile Qt.
-
** Emacs pauses for several seconds when changing the default font.
This has been reported for fvwm 2.2.5 and the window manager of KDE
to nil in your `.emacs'.
To see what is the value of UNDERLINE_POSITION defined by the font,
-type `xlsfonts -lll FONT' and look at the font's UNDERLINE_POSITION
-property.
+type `xlsfonts -lll FONT' and look at the font's UNDERLINE_POSITION property.
** When using Exceed, fonts sometimes appear too tall.
Many Spanish keyboards seem to ignore that combination. Emacs can't
do anything about it.
-** Characters from the mule-unicode charsets aren't displayed under X.
+** International characters aren't displayed under X.
+
+*** Missing X fonts
XFree86 4 contains many fonts in iso10646-1 encoding which have
minimal character repertoires (whereas the encoding part of the font
substituted with the Unicode `replacement character', and you lose
information.
-** Mule-UCS loads very slowly.
-
-Changes to Emacs internals interact badly with Mule-UCS's `un-define'
-library, which is the usual interface to Mule-UCS. Apply the
-following patch to Mule-UCS 0.84 and rebuild it. That will help,
-though loading will still be slower than in Emacs 20. (Some
-distributions, such as Debian, may already have applied such a patch.)
-
---- lisp/un-define.el 6 Mar 2001 22:41:38 -0000 1.30
-+++ lisp/un-define.el 19 Apr 2002 18:34:26 -0000
-@@ -610,13 +624,21 @@ by calling post-read-conversion and pre-
-
- (mapcar
- (lambda (x)
-- (mapcar
-- (lambda (y)
-- (mucs-define-coding-system
-- (nth 0 y) (nth 1 y) (nth 2 y)
-- (nth 3 y) (nth 4 y) (nth 5 y) (nth 6 y))
-- (coding-system-put (car y) 'alias-coding-systems (list (car x))))
-- (cdr x)))
-+ (if (fboundp 'register-char-codings)
-+ ;; Mule 5, where we don't need the eol-type specified and
-+ ;; register-char-codings may be very slow for these coding
-+ ;; system definitions.
-+ (let ((y (cadr x)))
-+ (mucs-define-coding-system
-+ (car x) (nth 1 y) (nth 2 y)
-+ (nth 3 y) (nth 4 y) (nth 5 y)))
-+ (mapcar
-+ (lambda (y)
-+ (mucs-define-coding-system
-+ (nth 0 y) (nth 1 y) (nth 2 y)
-+ (nth 3 y) (nth 4 y) (nth 5 y) (nth 6 y))
-+ (coding-system-put (car y) 'alias-coding-systems (list (car x)))))
-+ (cdr x)))
- `((utf-8
- (utf-8-unix
- ?u "UTF-8 coding system"
-
-Note that Emacs has native support for Unicode, roughly equivalent to
-Mule-UCS's, so you may not need it.
-
-** Mule-UCS compilation problem.
-
-Emacs of old versions and XEmacs byte-compile the form `(progn progn
-...)' the same way as `(progn ...)', but Emacs of version 21.3 and the
-later process that form just as interpreter does, that is, as `progn'
-variable reference. Apply the following patch to Mule-UCS 0.84 to
-make it compiled by the latest Emacs.
-
---- mucs-ccl.el 2 Sep 2005 00:42:23 -0000 1.1.1.1
-+++ mucs-ccl.el 2 Sep 2005 01:31:51 -0000 1.3
-@@ -639,10 +639,14 @@
- (mucs-notify-embedment 'mucs-ccl-required name)
- (setq ccl-pgm-list (cdr ccl-pgm-list)))
- ; (message "MCCLREGFIN:%S" result)
-- `(progn
-- (setq mucs-ccl-facility-alist
-- (quote ,mucs-ccl-facility-alist))
-- ,@result)))
-+ ;; The only way the function is used in this package is included
-+ ;; in `mucs-package-definition-end-hook' value, where it must
-+ ;; return (possibly empty) *list* of forms. Do this. Do not rely
-+ ;; on byte compiler to remove extra `progn's in `(progn ...)'
-+ ;; form.
-+ `((setq mucs-ccl-facility-alist
-+ (quote ,mucs-ccl-facility-alist))
-+ ,@result)))
-
- ;;; Add hook for embedding translation informations to a package.
- (add-hook 'mucs-package-definition-end-hook
-
** Accented ISO-8859-1 characters are displayed as | or _.
Try other font set sizes (S-mouse-1). If the problem persists with
xfd -fn -schumacher-clean-medium-r-normal--12-120-75-75-c-60-iso8859-1
-If this shows only ASCII glyphs, the font is indeed the source of the
-problem.
+If this shows only ASCII glyphs, the font is indeed the source of the problem.
The solution is to remove the corresponding lines from the appropriate
`fonts.alias' file, then run `mkfontdir' in that directory, and then run
If C-h c reports an event that doesn't have the Alt modifier, it may
be because your X server has no key for the Alt modifier. The X
-server that comes from MIT does not set up the Alt modifier by
-default.
+server that comes from MIT does not set up the Alt modifier by default.
If your keyboard has keys named Alt, you can enable them as follows:
** Window-manager and toolkit-related problems
+*** Metacity: Resizing Emacs or ALT-Tab causes X to be unresponsive.
+
+This happens sometimes when using Metacity. Resizing Emacs or ALT-Tab:bing
+makes the system unresponsive to the mouse or the keyboard. Killing Emacs
+or shifting out from X11 and back again usually cures it (i.e. Ctrl-Alt-F1
+and then Alt-F7). A bug for it is here:
+https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/231034.
+Note that a permanent fix seems to be to disable "assistive technologies".
+
*** Gnome: Emacs receives input directly from the keyboard, bypassing XIM.
This seems to happen when gnome-settings-daemon version 2.12 or later
On some systems, even with Motif 1.2 emulation, Emacs occasionally
locks up, grabbing all mouse and keyboard events. We still don't know
-what causes these problems; they are not reproducible by Emacs
-developers.
+what causes these problems; they are not reproducible by Emacs developers.
*** Motif: The Motif version of Emacs paints the screen a solid color.
One way to avoid this problem is to eliminate the type-1 fonts from
your font path, like this:
- xset -fp /usr/X11R6/lib/X11/fonts/Type1/
+ xset -fp /usr/X11R6/lib/X11/fonts/Type1/
*** Pull-down menus appear in the wrong place, in the toolkit version of Emacs.
your .emacs file. Another cause is a bad value of EMACSLOADPATH in
the environment.
-*** Emacs fails to get default settings from X Windows server.
-
-The X library in X11R4 has a bug; it interchanges the 2nd and 3rd
-arguments to XGetDefaults. Define the macro XBACKWARDS in config.h to
-tell Emacs to compensate for this.
-
-I don't believe there is any way Emacs can determine for itself
-whether this problem is present on a given system.
-
*** X Windows doesn't work if DISPLAY uses a hostname.
People have reported kernel bugs in certain systems that cause Emacs
However, that has the disadvantage of turning off interrupts, so that
you are unable to quit out of a Lisp program by typing C-g.
-The easy way to do this is to put
+*** Prevent double pastes in X
- (setq x-sigio-bug t)
+The problem: a region, such as a command, is pasted twice when you copy
+it with your mouse from GNU Emacs to an xterm or an RXVT shell in X.
+The solution: try the following in your X configuration file,
+/etc/X11/xorg.conf This should enable both PS/2 and USB mice for
+single copies. You do not need any other drivers or options.
-in your site-init.el file.
+ Section "InputDevice"
+ Identifier "Generic Mouse"
+ Driver "mousedev"
+ Option "Device" "/dev/input/mice"
+ EndSection
* Runtime problems on character terminals
+** The meta key does not work on xterm.
+Typing M-x rings the terminal bell, and inserts a string like ";120~".
+For recent xterm versions (>= 216), Emacs uses xterm's modifyOtherKeys
+feature to generate strings for key combinations that are not
+otherwise usable. One circumstance in which this can cause problems
+is if you have specified the X resource
+
+ xterm*VT100.Translations
+
+to contain translations that use the meta key. Then xterm will not
+use meta in modified function-keys, which confuses Emacs. To fix
+this, you can remove the X resource or put this in your init file:
+
+ (xterm-remove-modify-other-keys)
+
** Emacs spontaneously displays "I-search: " at the bottom of the screen.
This means that Control-S/Control-Q (XON/XOFF) "flow control" is being
First of all, many terminals have a set-up mode which controls whether
they generate XON/XOFF flow control characters. This must be set to
-"no XON/XOFF" in order for Emacs to work. Sometimes there is an
+"no XON/XOFF" in order for Emacs to work. (For example, on a VT220
+you may select "No XOFF" in the setup menu.) Sometimes there is an
escape sequence that the computer can send to turn flow control off
and on. If so, perhaps the termcap `ti' string should turn flow
control off, and the `te' string should turn it on.
need more padding, or possibly the terminal manual is wrong.
2) The characters sent are incorrect, due to an obscure aspect
- of the terminal behavior not described in an obvious way
- by termcap.
+ of the terminal behavior not described in an obvious way by termcap.
This case is hard. It will be necessary to think of a way for
Emacs to distinguish between terminals with this kind of behavior
Some versions of rlogin (and possibly telnet) do not pass flow
control characters to the remote system to which they connect.
On such systems, emacs on the remote system cannot disable flow
-control on the local system.
+control on the local system. Sometimes `rlogin -8' will avoid this problem.
One way to cure this is to disable flow control on the local host
(the one running rlogin, not the one running rlogind) using the
stty command, before starting the rlogin process. On many systems,
-"stty start u stop u" will do this.
+"stty start u stop u" will do this. On some systems, use
+"stty -ixon" instead.
Some versions of tcsh will prevent even this from working. One way
around this is to start another shell before starting rlogin, and
(enable-flow-control-on "vt200" "vt300" "vt101" "vt131")
-See the entry about spontaneous display of I-search (above) for more
-info.
+See the entry about spontaneous display of I-search (above) for more info.
** Output from Control-V is slow.
exec 2> >(exec cat >&2 2>/dev/null)
exec ssh "$@"
+*** GNU/Linux: Truncated svn annotate output with SSH.
+http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7791
+
+The symptoms are: you are accessing a svn repository over SSH.
+You use vc-annotate on a large (several thousand line) file, and the
+result is truncated around the 1000 line mark. It works fine with
+other access methods (eg http), or from outside Emacs.
+
+This may be a similar libc/SSH issue to the one mentioned above for CVS.
+A similar workaround seems to be effective: create a script with the
+same contents as the one used above for CVS_RSH, and set the SVN_SSH
+environment variable to point to it.
+
*** GNU/Linux: On Linux-based GNU systems using libc versions 5.4.19 through
5.4.22, Emacs crashes at startup with a segmentation fault.
** Solaris
-We list bugs in current versions here. Solaris 2.x and 4.x are covered in the
-section on legacy systems.
+We list bugs in current versions here. See also the section on legacy
+systems.
*** On Solaris, C-x doesn't get through to Emacs when you use the console.
is because the unshared libraries fail to use YP for host name lookup.
As a result, the host name you specify may not be recognized.
-*** Solaris 2,6: Emacs crashes with SIGBUS or SIGSEGV on Solaris after you delete a frame.
+*** Solaris 2.6: Emacs crashes with SIGBUS or SIGSEGV on Solaris after you delete a frame.
We suspect that this is a bug in the X libraries provided by
Sun. There is a report that one of these patches fixes the bug and
You can fix this by editing the file:
- /usr/openwin/lib/locale/iso8859-15/Compose
+ /usr/openwin/lib/locale/iso8859-15/Compose
Near the bottom there is a line that reads:
- Ctrl<t> <quotedbl> <Y> : "\276" threequarters
+ Ctrl<t> <quotedbl> <Y> : "\276" threequarters
that should read:
- Ctrl<T> <quotedbl> <Y> : "\276" threequarters
+ Ctrl<T> <quotedbl> <Y> : "\276" threequarters
Note the lower case <t>. Changing this line should make C-t work.
* Runtime problems specific to MS-Windows
+** PATH can contain unexpanded environment variables
+
+Old releases of TCC (version 9) and 4NT (up to version 8) do not correctly
+expand App Paths entries of type REG_EXPAND_SZ. When Emacs is run from TCC
+and such an entry exists for emacs.exe, exec-path will contain the
+unexpanded entry. This has been fixed in TCC 10. For more information,
+see bug#2062.
+
+** Setting w32-pass-rwindow-to-system and w32-pass-lwindow-to-system to nil
+does not prevent the Start menu from popping up when the left or right
+``Windows'' key is pressed.
+
+This was reported to happen when XKeymacs is installed. At least with
+XKeymacs Version 3.47, deactivating XKeymacs when Emacs is active is
+not enough to avoid its messing with the keyboard input. Exiting
+XKeymacs completely is reported to solve the problem.
+
** Windows 95 and networking.
To support server sockets, Emacs 22.1 loads ws2_32.dll. If this file
changes the keyboard layout depends on your Windows version; for XP,
in the Languages tab, click "Details" and then "Key Settings".)
-** Cygwin build of Emacs hangs after rebasing Cygwin DLLs
-
-Usually, on Cygwin, one needs to rebase the DLLs if an application
-aborts with a message like this:
-
- C:\cygwin\bin\python.exe: *** unable to remap C:\cygwin\bin\cygssl.dll to
- same address as parent(0xDF0000) != 0xE00000
-
-However, since Cygwin DLL 1.5.17 was released, after such rebasing,
-Emacs hangs.
-
-This was reported to happen for Emacs 21.2 and also for the pretest of
-Emacs 22.1 on Cygwin.
-
-To work around this, build Emacs like this:
-
- LDFLAGS='-Wl,--enable-auto-import -Wl,--enable-auto-image-base' ./configure
- make LD='$(CC)'
- make LD='$(CC)' install
-
-This produces an Emacs binary that is independent of rebasing.
-
-Note that you _must_ use LD='$(CC)' in the last two commands above, to
-prevent GCC from passing the "--image-base 0x20000000" option to the
-linker, which is what it does by default. That option produces an
-Emacs binary with the base address 0x20000000, which will cause Emacs
-to hang after Cygwin DLLs are rebased.
-
** Interrupting Cygwin port of Bash from Emacs doesn't work.
Cygwin 1.x builds of the ported Bash cannot be interrupted from the
Of this does not work, please inform bug-gnu-emacs@gnu.org. Then
please call support for your X-server and see if you can get a fix.
-If you do, please send it to bug-gnu-emacs@gnu.org so we can list it
-here.
+If you do, please send it to bug-gnu-emacs@gnu.org so we can list it here.
* Build-time problems
for your C compiler (CPP="/opt/SUNWspro/bin/cc -E" in the above
example).
-*** `configure' fails with ``"junk.c", line 660: invalid input token: 8.elc''
-
-The final stage of the Emacs configure process uses the C preprocessor
-to generate the Makefiles. Errors of this form can occur if the C
-preprocessor inserts extra whitespace into its output. The solution
-is to find the switches that stop your preprocessor from inserting extra
-whitespace, add them to CPPFLAGS, and re-run configure. For example,
-this error can occur on Solaris 10 when using the Sun Studio compiler
-``Sun C 5.8'' with its preprocessor CPP="/opt/SUNWspro/bin/cc -E".
-The relevant switch in this case is "-Xs" (``compile assuming
-(pre-ANSI) K & R C style code'').
-
** Compilation
*** Building Emacs over NFS fails with ``Text file busy''.
The solution is to remove this line from `etc/fstab'.
-*** Building Emacs with GCC 2.9x fails in the `src' directory.
-
-This may happen if you use a development version of GNU `cpp' from one
-of the GCC snapshots between Oct 2000 and Feb 2001, or from a released
-version of GCC newer than 2.95.2 which was prepared around those
-dates; similar problems were reported with some snapshots of GCC 3.1
-around Sep 30 2001. The preprocessor in those versions is
-incompatible with a traditional Unix cpp (e.g., it expands ".." into
-". .", which breaks relative file names that reference the parent
-directory; or inserts TAB characters before lines that set Make
-variables).
-
-The solution is to make sure the preprocessor is run with the
-`-traditional' option. The `configure' script does that automatically
-when it detects the known problems in your cpp, but you might hit some
-unknown ones. To force the `configure' script to use `-traditional',
-run the script like this:
+*** Building a 32-bit executable on a 64-bit GNU/Linux architecture.
- CPP='gcc -E -traditional' ./configure ...
+First ensure that the necessary 32-bit system libraries and include
+files are installed. Then use:
-(replace the ellipsis "..." with any additional arguments you pass to
-the script).
+ env CC="gcc -m32" ./configure --build=i386-linux-gnu \
+ --x-libraries=/usr/X11R6/lib
-Note that this problem does not pertain to the MS-Windows port of
-Emacs, since it doesn't use the preprocessor to generate Makefiles.
+(using the location of the 32-bit X libraries on your system).
-*** src/Makefile and lib-src/Makefile are truncated--most of the file missing.
-*** Compiling wakeup, in lib-src, says it can't make wakeup.c.
+*** Building Emacs for Cygwin can fail with GCC 3
-This can happen if configure uses GNU sed version 2.03. That version
-had a bug. GNU sed version 2.05 works properly.To solve the
-problem, install the current version of GNU Sed, then rerun Emacs's
-configure script.
+As of Emacs 22.1, there have been stability problems with Cygwin
+builds of Emacs using GCC 3. Cygwin users are advised to use GCC 4.
-*** Compiling lib-src says there is no rule to make test-distrib.c.
+*** Building Emacs 23.3 and later will fail under Cygwin 1.5.19
-This results from a bug in a VERY old version of GNU Sed. To solve
-the problem, install the current version of GNU Sed, then rerun
-Emacs's configure script.
+This is a consequence of a change to src/dired.c on 2010-07-27. The
+issue is that Cygwin 1.5.19 did not have d_ino in 'struct dirent'.
+See
-*** Building a 32-bit executable on a 64-bit GNU/Linux architecture.
+ http://lists.gnu.org/archive/html/emacs-devel/2010-07/msg01266.html
-First ensure that the necessary 32-bit system libraries and include
-files are installed. Then use:
+*** Building the native MS-Windows port fails due to unresolved externals
- env CC="gcc -m32" ./configure --build=i386-linux-gnu \
- --x-libraries=/usr/X11R6/lib
+The linker error messages look like this:
-(using the location of the 32-bit X libraries on your system).
+ oo-spd/i386/ctags.o:ctags.c:(.text+0x156e): undefined reference to `_imp__re_set_syntax'
+ collect2: ld returned 1 exit status
-*** Building the Cygwin port for MS-Windows can fail with some GCC versions
+This happens because GCC finds an incompatible header regex.h
+somewhere on the include path, before the version of regex.h supplied
+with Emacs. One such incompatible version of regex.h is part of the
+GnuWin32 Regex package.
-Building Emacs 22 with Cygwin builds of GCC 3.4.4-1 and 3.4.4-2 is
-reported to either fail or cause Emacs to segfault at run time. In
-addition, the Cygwin GCC 3.4.4-2 has problems with generating debug
-info. Cygwin users are advised not to use these versions of GCC for
-compiling Emacs. GCC versions 4.0.3, 4.0.4, 4.1.1, and 4.1.2
-reportedly build a working Cygwin binary of Emacs, so we recommend
-these GCC versions. Note that these versions of GCC, 4.0.3, 4.0.4,
-4.1.1, and 4.1.2, are currently the _only_ versions known to succeed
-in building Emacs (as of v22.1).
+The solution is to remove the incompatible regex.h from the include
+path, when compiling Emacs. Alternatively, re-run the configure.bat
+script with the "-isystem C:/GnuWin32/include" switch (adapt for your
+system's place where you keep the GnuWin32 include files) -- this will
+cause the compiler to search headers in the directories specified by
+the Emacs Makefile _before_ it looks in the GnuWin32 include
+directories.
*** Building the native MS-Windows port with Cygwin GCC can fail.
conflict between the versions of malloc in the DLL and in Emacs, which
is not resolvable due to the way Windows does dynamic linking.
-We recommend the use of the MingW port of GCC for compiling Emacs, as
+We recommend the use of the MinGW port of GCC for compiling Emacs, as
not only does it not suffer these problems, but it is also Free
software like Emacs.
+*** Building the MS-Windows port with Visual Studio fails compiling emacs.rc
+
+If the build fails with the following message then the problem
+described here most likely applies:
+
+../nt/emacs.rc(1) : error RC2176 : old DIB in icons\emacs.ico; pass it
+through SDKPAINT
+
+The Emacs icon contains a high resolution PNG icon for Vista, which is
+not recognized by older versions of the resource compiler. There are
+several workarounds for this problem:
+ 1. Use Free MinGW tools to compile, which do not have this problem.
+ 2. Install the latest Windows SDK.
+ 3. Replace emacs.ico with an older or edited icon.
+
+*** Building the MS-Windows port complains about unknown escape sequences.
+
+Errors and warnings can look like this:
+
+ w32.c:1959:27: error: \x used with no following hex digits
+ w32.c:1959:27: warning: unknown escape sequence '\i'
+
+This happens when paths using backslashes are passed to the compiler or
+linker (via -I and possibly other compiler flags); when these paths are
+included in source code, the backslashes are interpreted as escape sequences.
+See http://lists.gnu.org/archive/html/emacs-devel/2010-07/msg00995.html
+
+The fix is to use forward slashes in all paths passed to the compiler.
+
** Linking
*** Building Emacs with a system compiler fails to link because of an
A solution is to link with GCC, like this:
- make CC=gcc
+ make CC=gcc
Since the .o object files already exist, this will not recompile Emacs
with GCC, but just restart by trying again to link temacs.
-*** AIX 1.3 ptf 0013: Link failure.
-
-There is a real duplicate definition of the function `_slibc_free' in
-the library /lib/libc_s.a (just do nm on it to verify). The
-workaround/fix is:
-
- cd /lib
- ar xv libc_s.a NLtmtime.o
- ar dv libc_s.a NLtmtime.o
-
-*** AIX 4.1.2: Linker error messages such as
- ld: 0711-212 SEVERE ERROR: Symbol .__quous, found in the global symbol table
- of archive /usr/lib/libIM.a, was not defined in archive member shr.o.
-
-This is a problem in libIM.a. You can work around it by executing
-these shell commands in the src subdirectory of the directory where
-you build Emacs:
-
- cp /usr/lib/libIM.a .
- chmod 664 libIM.a
- ranlib libIM.a
-
-Then change -lIM to ./libIM.a in the command to link temacs (in
-Makefile).
-
*** Sun with acc: Link failure when using acc on a Sun.
To use acc, you need additional options just before the libraries, such as
The fix is to install a newer version of ncurses, such as version 4.2.
+** Bootstrapping
+
+Bootstrapping (compiling the .el files) is normally only necessary
+with development builds, since the .elc files are pre-compiled in releases.
+
+*** "No rule to make target" with Ubuntu 8.04 make 3.81-3build1
+
+Compiling the lisp files fails at random places, complaining:
+"No rule to make target `/path/to/some/lisp.elc'".
+The causes of this problem are not understood. Using GNU make 3.81 compiled
+from source, rather than the Ubuntu version, worked. See Bug#327,821.
+
** Dumping
*** Linux: Segfault during `make bootstrap' under certain recent versions of the Linux kernel.
*** temacs prints "Pure Lisp storage exhausted".
-This means that the Lisp code loaded from the .elc and .el
-files during temacs -l loadup inc dump took up more
-space than was allocated.
+This means that the Lisp code loaded from the .elc and .el files
+during temacs -l loadup inc dump took up more space than was allocated.
This could be caused by
1) adding code to the preloaded Lisp files
2) adding more preloaded files in loadup.el
3) having a site-init.el or site-load.el which loads files.
Note that ANY site-init.el or site-load.el is nonstandard;
- if you have received Emacs from some other site
- and it contains a site-init.el or site-load.el file, consider
- deleting that file.
+ if you have received Emacs from some other site and it contains a
+ site-init.el or site-load.el file, consider deleting that file.
4) getting the wrong .el or .elc files
(not from the directory you expected).
5) deleting some .elc files that are supposed to exist.
This would cause the source files (.el files) to be
loaded instead. They take up more room, so you lose.
- 6) a bug in the Emacs distribution which underestimates
- the space required.
+ 6) a bug in the Emacs distribution which underestimates the space required.
If the need for more space is legitimate, change the definition
of PURESIZE in puresize.h.
But in some of the cases listed above, this problem is a consequence
-of something else that is wrong. Be sure to check and fix the real
-problem.
+of something else that is wrong. Be sure to check and fix the real problem.
*** Linux: Emacs crashes when dumping itself on Mac PPC running Yellow Dog GNU/Linux.
distribution:
#if 0 /* This breaks things on PPC GNU/Linux except for Yellowdog,
- even with identical GCC, as, ld. Let's take it out until we
- know what's really going on here. */
+ even with identical GCC, as, ld. Let's take it out until we
+ know what's really going on here. */
/* GCC 2.95 and newer on GNU/Linux PPC changed the load address to
0x10000000. */
#if defined __linux__
Two causes have been seen for such problems.
1) On a system where getpagesize is not a system call, it is defined
-as a macro. If the definition (in both unexec.c and malloc.c) is wrong,
+as a macro. If the definition (in both unex*.c and malloc.c) is wrong,
it can cause problems like this. You might be able to find the correct
value in the man page for a.out (5).
not initialized are not supposed to be pure. On these systems you
may need to add "#define static" to the m- or the s- file.
-* Emacs 19 problems
-
-** Error messages `Wrong number of arguments: #<subr where-is-internal>, 5'.
-
-This typically results from having the powerkey library loaded.
-Powerkey was designed for Emacs 19.22. It is obsolete now because
-Emacs 19 now has this feature built in; and powerkey also calls
-where-is-internal in an obsolete way.
-
-So the fix is to arrange not to load powerkey.
-
* Runtime problems on legacy systems
This section covers bugs reported on very old hardware or software.
If you are using hardware and an operating system shipped after 2000,
it is unlikely you will see any of these.
-** Ancient operating systems
-
-AIX 4.2 was end-of-lifed on Dec 31st, 1999.
-
-*** AIX: You get this compiler error message:
-
- Processing include file ./XMenuInt.h
- 1501-106: (S) Include file X11/Xlib.h not found.
-
-This means your system was installed with only the X11 runtime i.d
-libraries. You have to find your sipo (bootable tape) and install
-X11Dev... with smit.
-
-(This report must be ancient. Bootable tapes are long dead.)
-
-*** AIX 3.2.4: Releasing Ctrl/Act key has no effect, if Shift is down.
-
-Due to a feature of AIX, pressing or releasing the Ctrl/Act key is
-ignored when the Shift, Alt or AltGr keys are held down. This can
-lead to the keyboard being "control-locked"--ordinary letters are
-treated as control characters.
-
-You can get out of this "control-locked" state by pressing and
-releasing Ctrl/Act while not pressing or holding any other keys.
-
-*** AIX 3.2.5: You get this message when running Emacs:
-
- Could not load program emacs
- Symbol smtcheckinit in csh is undefined
- Error was: Exec format error
-
-or this one:
-
- Could not load program .emacs
- Symbol _system_con in csh is undefined
- Symbol _fp_trapsta in csh is undefined
- Error was: Exec format error
-
-These can happen when you try to run on AIX 3.2.5 a program that was
-compiled with 3.2.4. The fix is to recompile.
-
-*** AIX 4.2: Emacs gets a segmentation fault at startup.
-
-If you are using IBM's xlc compiler, compile emacs.c
-without optimization; that should avoid the problem.
-
-*** ISC Unix
-
-**** ISC: display-time causes kernel problems on ISC systems.
-
-Under Interactive Unix versions 3.0.1 and 4.0 (and probably other
-versions), display-time causes the loss of large numbers of STREVENT
-cells. Eventually the kernel's supply of these cells is exhausted.
-This makes emacs and the whole system run slow, and can make other
-processes die, in particular pcnfsd.
-
-Other emacs functions that communicate with remote processes may have
-the same problem. Display-time seems to be far the worst.
-
-The only known fix: Don't run display-time.
-
-**** Sunos 5.3: Subprocesses remain, hanging but not zombies.
-
-A bug in Sunos 5.3 causes Emacs subprocesses to remain after Emacs
-exits. Sun patch # 101415-02 is part of the fix for this, but it only
-applies to ptys, and doesn't fix the problem with subprocesses
-communicating through pipes.
-
-*** Irix
-
-*** Irix 6.2: No visible display on mips-sgi-irix6.2 when compiling with GCC 2.8.1.
-
-This problem went away after installing the latest IRIX patches
-as of 8 Dec 1998.
-
-The same problem has been reported on Irix 6.3.
-
-*** Irix 6.3: substituting environment variables in file names
-in the minibuffer gives peculiar error messages such as
-
- Substituting nonexistent environment variable ""
-
-This is not an Emacs bug; it is caused by something in SGI patch
-003082 August 11, 1998.
-
-*** OPENSTEP
-
-**** OPENSTEP 4.2: Compiling syntax.c with gcc 2.7.2.1 fails.
+*** OPENSTEP 4.2: Compiling syntax.c with gcc 2.7.2.1 fails.
The compiler was reported to crash while compiling syntax.c with the
following message:
This can happen if you configure Emacs without specifying the precise
version of Solaris that you are using.
-**** Solaris 2.3 and 2.4: Unpredictable segmentation faults.
-
-A user reported that this happened in 19.29 when it was compiled with
-the Sun compiler, but not when he recompiled with GCC 2.7.0.
-
-We do not know whether something in Emacs is partly to blame for this.
-
-**** Solaris 2.4: Emacs dumps core on startup.
-
-Bill Sebok says that the cause of this is Solaris 2.4 vendor patch
-102303-05, which extends the Solaris linker to deal with the Solaris
-Common Desktop Environment's linking needs. You can fix the problem
-by removing this patch and installing patch 102049-02 instead.
-However, that linker version won't work with CDE.
-
-Solaris 2.5 comes with a linker that has this bug. It is reported that if
-you install all the latest patches (as of June 1996), the bug is fixed.
-We suspect the crucial patch is one of these, but we don't know
-for certain.
-
- 103093-03: [README] SunOS 5.5: kernel patch (2140557 bytes)
- 102832-01: [README] OpenWindows 3.5: Xview Jumbo Patch (4181613 bytes)
- 103242-04: [README] SunOS 5.5: linker patch (595363 bytes)
-
-(One user reports that the bug was fixed by those patches together
-with patches 102980-04, 103279-01, 103300-02, and 103468-01.)
-
-If you can determine which patch does fix the bug, please tell
-bug-gnu-emacs@gnu.org.
-
-Meanwhile, the GNU linker links Emacs properly on both Solaris 2.4 and
-Solaris 2.5.
-
-**** Solaris 2.4: Dired hangs and C-g does not work. Or Emacs hangs
-forever waiting for termination of a subprocess that is a zombie.
-
-casper@fwi.uva.nl says the problem is in X11R6. Rebuild libX11.so
-after changing the file xc/config/cf/sunLib.tmpl. Change the lines
-
- #if ThreadedX
- #define SharedX11Reqs -lthread
- #endif
-
-to:
-
- #if OSMinorVersion < 4
- #if ThreadedX
- #define SharedX11Reqs -lthread
- #endif
- #endif
-
-Be sure also to edit x/config/cf/sun.cf so that OSMinorVersion is 4
-(as it should be for Solaris 2.4). The file has three definitions for
-OSMinorVersion: the first is for x86, the second for SPARC under
-Solaris, and the third for SunOS 4. Make sure to update the
-definition for your type of machine and system.
-
-Then do `make Everything' in the top directory of X11R6, to rebuild
-the makefiles and rebuild X. The X built this way work only on
-Solaris 2.4, not on 2.3.
-
-For multithreaded X to work it is necessary to install patch
-101925-02 to fix problems in header files [2.4]. You need
-to reinstall gcc or re-run just-fixinc after installing that
-patch.
-
-However, Frank Rust <frust@iti.cs.tu-bs.de> used a simpler solution:
-he changed
- #define ThreadedX YES
-to
- #define ThreadedX NO
-in sun.cf and did `make World' to rebuild X11R6. Removing all
-`-DXTHREAD*' flags and `-lthread' entries from lib/X11/Makefile and
-typing 'make install' in that directory also seemed to work.
-
**** Solaris 2.x: GCC complains "64 bit integer types not supported".
This suggests that GCC is not installed correctly. Most likely you
should do.
pen@lysator.liu.se says (Feb 1998) that the Compose key does work
-if you link with the MIT X11 libraries instead of the Solaris X11
-libraries.
-
-*** HP/UX versions before 11.0
-
-HP/UX 9 was end-of-lifed in December 1998.
-HP/UX 10 was end-of-lifed in May 1999.
-
-**** HP/UX 9: Emacs crashes with SIGBUS or SIGSEGV after you delete a frame.
-
-We think this is due to a bug in the X libraries provided by HP. With
-the alternative X libraries in /usr/contrib/mitX11R5/lib, the problem
-does not happen.
+if you link with the MIT X11 libraries instead of the Solaris X11 libraries.
*** HP/UX 10: Large file support is disabled.
-
-See the comments in src/s/hpux10.h.
+(HP/UX 10 was end-of-lifed in May 1999.)
+See the comments in src/s/hpux10-20.h.
*** HP/UX: Emacs is slow using X11R5.
those libraries installed. To get good performance, you need to
install them and rebuild Emacs.
-*** Ultrix and Digital Unix
-
-**** Ultrix 4.2: `make install' fails on install-doc with `Error 141'.
-
-This happens on Ultrix 4.2 due to failure of a pipeline of tar
-commands. We don't know why they fail, but the bug seems not to be in
-Emacs. The workaround is to run the shell command in install-doc by
-hand.
-
-**** Digital Unix 4.0: Garbled display on non-X terminals when Emacs runs.
-
-So far it appears that running `tset' triggers this problem (when TERM
-is vt100, at least). If you do not run `tset', then Emacs displays
-properly. If someone can tell us precisely which effect of running
-`tset' actually causes the problem, we may be able to implement a fix
-in Emacs.
-
-**** Ultrix: `expand-file-name' fails to work on any but the machine you dumped Emacs on.
-
-On Ultrix, if you use any of the functions which look up information
-in the passwd database before dumping Emacs (say, by using
-expand-file-name in site-init.el), then those functions will not work
-in the dumped Emacs on any host but the one Emacs was dumped on.
-
-The solution? Don't use expand-file-name in site-init.el, or in
-anything it loads. Yuck - some solution.
-
-I'm not sure why this happens; if you can find out exactly what is
-going on, and perhaps find a fix or a workaround, please let us know.
-Perhaps the YP functions cache some information, the cache is included
-in the dumped Emacs, and is then inaccurate on any other host.
-
-*** SVr4
-
-**** SVr4: On some variants of SVR4, Emacs does not work at all with X.
-
-Try defining BROKEN_FIONREAD in your config.h file. If this solves
-the problem, please send a bug report to tell us this is needed; be
-sure to say exactly what type of machine and system you are using.
-
-**** SVr4: After running emacs once, subsequent invocations crash.
-
-Some versions of SVR4 have a serious bug in the implementation of the
-mmap () system call in the kernel; this causes emacs to run correctly
-the first time, and then crash when run a second time.
-
-Contact your vendor and ask for the mmap bug fix; in the mean time,
-you may be able to work around the problem by adding a line to your
-operating system description file (whose name is reported by the
-configure script) that reads:
-#define SYSTEM_MALLOC
-This makes Emacs use memory less efficiently, but seems to work around
-the kernel bug.
-
-*** Irix 5 and earlier
-
-Exactly when Irix-5 end-of-lifed is obscure. But since Irix 6.0
-shipped in 1994, it has been some years.
-
-**** Irix 5.2: unexelfsgi.c can't find cmplrs/stsupport.h.
-
-The file cmplrs/stsupport.h was included in the wrong file set in the
-Irix 5.2 distribution. You can find it in the optional fileset
-compiler_dev, or copy it from some other Irix 5.2 system. A kludgy
-workaround is to change unexelfsgi.c to include sym.h instead of
-syms.h.
-
-**** Irix 5.3: "out of virtual swap space".
-
-This message occurs when the system runs out of swap space due to too
-many large programs running. The solution is either to provide more
-swap space or to reduce the number of large programs being run. You
-can check the current status of the swap space by executing the
-command `swap -l'.
-
-You can increase swap space by changing the file /etc/fstab. Adding a
-line like this:
-
-/usr/swap/swap.more swap swap pri=3 0 0
-
-where /usr/swap/swap.more is a file previously created (for instance
-by using /etc/mkfile), will increase the swap space by the size of
-that file. Execute `swap -m' or reboot the machine to activate the
-new swap area. See the manpages for `swap' and `fstab' for further
-information.
-
-The objectserver daemon can use up lots of memory because it can be
-swamped with NIS information. It collects information about all users
-on the network that can log on to the host.
-
-If you want to disable the objectserver completely, you can execute
-the command `chkconfig objectserver off' and reboot. That may disable
-some of the window system functionality, such as responding CDROM
-icons.
-
-You can also remove NIS support from the objectserver. The SGI `admin'
-FAQ has a detailed description on how to do that; see question 35
-("Why isn't the objectserver working?"). The admin FAQ can be found at
-ftp://viz.tamu.edu/pub/sgi/faq/.
-
-**** Irix 5.3: Emacs crashes in utmpname.
-
-This problem is fixed in Patch 3175 for Irix 5.3.
-It is also fixed in Irix versions 6.2 and up.
-
-**** Irix 6.0: Make tries (and fails) to build a program named unexelfsgi.
-
-A compiler bug inserts spaces into the string "unexelfsgi . o"
-in src/Makefile. Edit src/Makefile, after configure is run,
-find that string, and take out the spaces.
-
-Compiler fixes in Irix 6.0.1 should eliminate this problem.
-
-*** SCO Unix and UnixWare
-
-**** SCO 3.2v4: Unusable default font.
-
-The Open Desktop environment comes with default X resource settings
-that tell Emacs to use a variable-width font. Emacs cannot use such
-fonts, so it does not work.
-
-This is caused by the file /usr/lib/X11/app-defaults/ScoTerm, which is
-the application-specific resource file for the `scoterm' terminal
-emulator program. It contains several extremely general X resources
-that affect other programs besides `scoterm'. In particular, these
-resources affect Emacs also:
-
- *Font: -*-helvetica-medium-r-*--12-*-p-*
- *Background: scoBackground
- *Foreground: scoForeground
-
-The best solution is to create an application-specific resource file for
-Emacs, /usr/lib/X11/sco/startup/Emacs, with the following contents:
-
- Emacs*Font: -*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-1
- Emacs*Background: white
- Emacs*Foreground: black
-
-(These settings mimic the Emacs defaults, but you can change them to
-suit your needs.) This resource file is only read when the X server
-starts up, so you should restart it by logging out of the Open Desktop
-environment or by running `scologin stop; scologin start` from the shell
-as root. Alternatively, you can put these settings in the
-/usr/lib/X11/app-defaults/Emacs resource file and simply restart Emacs,
-but then they will not affect remote invocations of Emacs that use the
-Open Desktop display.
-
-These resource files are not normally shared across a network of SCO
-machines; you must create the file on each machine individually.
-
-**** SCO 4.2.0: Regular expressions matching bugs on SCO systems.
-
-On SCO, there are problems in regexp matching when Emacs is compiled
-with the system compiler. The compiler version is "Microsoft C
-version 6", SCO 4.2.0h Dev Sys Maintenance Supplement 01/06/93; Quick
-C Compiler Version 1.00.46 (Beta). The solution is to compile with
-GCC.
-
-**** UnixWare 2.1: Error 12 (virtual memory exceeded) when dumping Emacs.
+*** UnixWare 2.1: Error 12 (virtual memory exceeded) when dumping Emacs.
Paul Abrahams (abrahams@acm.org) reports that with the installed
virtual memory settings for UnixWare 2.1.2, an Error 12 occurs during
(He recommends you not change the stack limit, though.)
These changes take effect when you reboot.
-*** Linux 1.x
-
-**** Linux 1.0-1.04: Typing C-c C-c in Shell mode kills your X server.
-
-This happens with Linux kernel 1.0 thru 1.04, approximately. The workaround is
-to define SIGNALS_VIA_CHARACTERS in config.h and recompile Emacs.
-Newer Linux kernel versions don't have this problem.
-
-**** Linux 1.3: Output from subprocess (such as man or diff) is randomly
-truncated on GNU/Linux systems.
-
-This is due to a kernel bug which seems to be fixed in Linux version
-1.3.75.
-
-** Windows 3.1, 95, 98, and ME
+** MS-Windows 95, 98, ME, and NT
*** MS-Windows NT/95: Problems running Perl under Emacs
--- PERL/LIB/PERLDB.PL Mon Jul 01 15:28:16 1996
***************
*** 68,74 ****
- $rcfile=".perldb";
+ $rcfile=".perldb";
}
else {
! $console = "con";
- $rcfile="perldb.ini";
+ $rcfile="perldb.ini";
}
--- 68,74 ----
- $rcfile=".perldb";
+ $rcfile=".perldb";
}
else {
! $console = "";
- $rcfile="perldb.ini";
+ $rcfile="perldb.ini";
}
--- perl/5.001/lib/perl5db.pl Mon Jul 01 17:00:08 1996
***************
*** 22,28 ****
- $rcfile=".perldb";
+ $rcfile=".perldb";
}
elsif (-e "con") {
! $console = "con";
- $rcfile="perldb.ini";
+ $rcfile="perldb.ini";
}
else {
--- 22,28 ----
- $rcfile=".perldb";
+ $rcfile=".perldb";
}
elsif (-e "con") {
! $console = "";
- $rcfile="perldb.ini";
+ $rcfile="perldb.ini";
}
else {
When a program you are trying to run is not found on the PATH,
Windows might respond by crashing or locking up your system. In
particular, this has been reported when trying to compile a Java
-program in JDEE when javac.exe is installed, but not on the system
-PATH.
+program in JDEE when javac.exe is installed, but not on the system PATH.
** MS-DOS
-*** When compiling with DJGPP on MS-Windows NT, "config msdos" fails.
+*** When compiling with DJGPP on MS-Windows NT or later, "config msdos" fails.
If the error message is "VDM has been already loaded", this is because
Windows has a program called `redir.exe' that is incompatible with a
config.bat. To resolve this, move the DJGPP's `bin' subdirectory to
the front of your PATH environment variable.
+*** When Emacs compiled with DJGPP runs on Windows 2000 and later, it cannot
+find your HOME directory.
+
+This was reported to happen when you click on "Save for future
+sessions" button in a Customize buffer. You might see an error
+message like this one:
+
+ basic-save-buffer-2: c:/FOO/BAR/~dosuser/: no such directory
+
+(The telltale sign is the "~USER" part at the end of the directory
+Emacs complains about, where USER is your username or the literal
+string "dosuser", which is the default username set up by the DJGPP
+startup file DJGPP.ENV.)
+
+This happens when the functions `user-login-name' and
+`user-real-login-name' return different strings for your username as
+Emacs sees it. To correct this, make sure both USER and USERNAME
+environment variables are set to the same value. Windows 2000 and
+later sets USERNAME, so if you want to keep that, make sure USER is
+set to the same value. If you don't want to set USER globally, you
+can do it in the [emacs] section of your DJGPP.ENV file.
+
+*** When Emacs compiled with DJGPP runs on Vista, it runs out of memory.
+
+If Emacs running on Vista displays "!MEM FULL!" in the mode line, you
+are hitting the memory allocation bugs in the Vista DPMI server. See
+msdos/INSTALL for how to work around these bugs (search for "Vista").
+
*** When compiling with DJGPP on MS-Windows 95, Make fails for some targets
like make-docfile.
This can happen if long file name support (the setting of environment
variable LFN) when Emacs distribution was unpacked and during
-compilation are not the same. See the MSDOG section of INSTALL for
-the explanation of how to avoid this problem.
+compilation are not the same. See msdos/INSTALL for the explanation
+of how to avoid this problem.
*** Emacs compiled with DJGPP complains at startup:
*** MS-DOS: Emacs crashes at startup.
Some users report that Emacs 19.29 requires dpmi memory management,
-and crashes on startup if the system does not have it. We don't yet
+and crashes on startup if the system does not have it. We don't
know why this happens--perhaps these machines don't have enough real
memory, or perhaps something is wrong in Emacs or the compiler.
However, arranging to use dpmi support is a workaround.
device names such as /dev/null in the DJGPP runtime library. A
work-around is to rename the problem directory to another name.
-*** MS-DOS+DJGPP: Problems on MS-DOG if DJGPP v2.0 is used to compile Emacs.
+*** MS-DOS+DJGPP: Problems on MS-DOS if DJGPP v2.0 is used to compile Emacs.
There are two DJGPP library bugs which cause problems:
and stderr to a file to see the error message printed by Emacs.
Another manifestation of this problem is that Emacs is unable to load
-the support for editing program sources in languages such as C and
-Lisp.
+the support for editing program sources in languages such as C and Lisp.
This can happen if the Emacs distribution was unzipped without LFN
support, thus causing long filenames to be truncated to the first 6
characters and a numeric tail that Windows 95 normally attaches to it.
You should unzip the files again with a utility that supports long
filenames (such as djtar from DJGPP or InfoZip's UnZip program
-compiled with DJGPP v2). The MSDOG section of the file INSTALL
-explains this issue in more detail.
+compiled with DJGPP v2). The file msdos/INSTALL explains this issue
+in more detail.
Another possible reason for such failures is that Emacs compiled for
MSDOS is used on Windows NT, where long file names are not supported
OpenWindows.WindowMenuAccelerators: False
-**** twm: A position you specified in .Xdefaults is ignored, using twm.
+*** twm: A position you specified in .Xdefaults is ignored, using twm.
twm normally ignores "program-specified" positions.
You can tell it to obey them with this command in your `.twmrc' file:
* Build problems on legacy systems
-** BSD/386 1.0: --with-x-toolkit option configures wrong.
-
-This problem is due to bugs in the shell in version 1.0 of BSD/386.
-The workaround is to edit the configure file to use some other shell,
-such as bash.
-
-** Digital Unix 4.0: Emacs fails to build, giving error message
- Invalid dimension for the charset-ID 160
-
-This is due to a bug or an installation problem in GCC 2.8.0.
-Installing a more recent version of GCC fixes the problem.
-
-** Digital Unix 4.0: Failure in unexec while dumping emacs.
-
-This problem manifests itself as an error message
-
- unexec: Bad address, writing data section to ...
-
-The user suspects that this happened because his X libraries
-were built for an older system version,
-
- ./configure --x-includes=/usr/include --x-libraries=/usr/shlib
-
-made the problem go away.
-
-** Sunos 4.1.1: there are errors compiling sysdep.c.
-
-If you get errors such as
-
- "sysdep.c", line 2017: undefined structure or union
- "sysdep.c", line 2017: undefined structure or union
- "sysdep.c", line 2019: nodename undefined
-
-This can result from defining LD_LIBRARY_PATH. It is very tricky
-to use that environment variable with Emacs. The Emacs configure
-script links many test programs with the system libraries; you must
-make sure that the libraries available to configure are the same
-ones available when you build Emacs.
-
-** 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
-
-The problem is in the Sun shared C library, not in GNU ld.
-
-The solution is to install Patch-ID# 100267-03 from Sun.
-
-** Sunos 4.1: Undefined symbols when linking using --with-x-toolkit.
-
-If you get the undefined symbols _atowc _wcslen, _iswprint, _iswspace,
-_iswcntrl, _wcscpy, and _wcsncpy, then you need to add -lXwchar after
--lXaw in the command that links temacs.
-
-This problem seems to arise only when the international language
-extensions to X11R5 are installed.
-
** SunOS: Emacs gets error message from linker on Sun.
If the error message says that a symbol such as `f68881_used' or
This problem will only happen if USE_LISP_UNION_TYPE is manually
defined in lisp.h.
-*** C compilers lose on returning unions.
+** C compilers lose on returning unions.
I hear that some C compilers cannot handle returning a union type.
Most of the functions in GNU Emacs return type Lisp_Object, which is
\f
Local variables:
mode: outline
-paragraph-separate: "[ \f]*$"
+paragraph-separate: "[ \f]*$"
end:
-
-arch-tag: 49fc0d95-88cb-4715-b21c-f27fb5a4764a
HCoop / bpt / emacs.git / blobdiff