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
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.)
* Mule-UCS doesn't work in Emacs 23.
+/* $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.
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.
-** Emacs compiled with Gtk+ crashes on startup on Cygwin.
-
-A typical error message is
- ***MEMORY-ERROR***: emacs[5172]: GSlice: failed to allocate 504 bytes
- (alignment: 512): Function not implemented
+** Emacs compiled with Gtk+ may loop forever if a display crashes.
-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.
+This is related to the bug above. A scenario for this is when emacs is run
+as a server, and an X frame is created. If the X server for the frame
+crashes or exits unexpectedly and an attempt is made to create a new
+frame on another X display, then a Gtk+ error happens in the emacs
+server that results in an endless loop. This is not fixed in any known
+Gtk+ version (2.14.4 being current).
* General runtime problems
`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
--- 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
- {
+ proc->p_returnval = deallocate_fd(proc, msg->m_args[0]);
+ else
+ {
** PSGML
* 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.
-** Certain fonts make each line take one pixel more than it "should".
+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
-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.
+http://lists.gnu.org/archive/html/emacs-devel/2008-10/msg00696.html
+
+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
This is caused by fonts having a wrong UNDERLINE_POSITION property.
Examples are the font 7x13 on XFree prior to version 4.1, or the jmk
-neep font from the Debian xfonts-jmk package. To circumvent this
-problem, set x-use-underline-position-properties to nil in your
-`.emacs'.
+neep font from the Debian xfonts-jmk package prior to version 3.0.17.
+To circumvent this problem, set x-use-underline-position-properties
+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
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
mule-unicode-e000-ffff:-gnu-unifont-*-iso10646-1,\
mule-unicode-0100-24ff:-gnu-unifont-*-iso10646-1
+*** Athena/Lucid toolkit limitations
+
+The Athena/Lucid toolkit cannot display UTF-8 strings in the menu, so
+if you have UTF-8 buffer names, the buffer menu won't display the
+names properly. The GTK+ toolkit works properly.
+
** The UTF-8/16/7 coding systems don't encode CJK (Far Eastern) characters.
Emacs directly supports the Unicode BMP whose code points are in the
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
** 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
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.
in your site-init.el file.
+*** Prevent double pastes in X
+
+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.
+
+ 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.
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
Using the old library version is a workaround.
-** Mac OS X
-
-*** Mac OS X (Carbon): Environment Variables from dotfiles are ignored.
-
-When starting Emacs from the Dock or the Finder on Mac OS X, the
-environment variables that are set up in dotfiles, such as .cshrc or
-.profile, are ignored. This is because the Finder and Dock are not
-started from a shell, but instead from the Window Manager itself.
-
-The workaround for this is to create a .MacOSX/environment.plist file to
-setup these environment variables. These environment variables will
-apply to all processes regardless of where they are started.
-For me information, see http://developer.apple.com/qa/qa2001/qa1067.html.
-
-*** Mac OS X (Carbon): Process output truncated when using ptys.
-
-There appears to be a problem with the implementation of pty's on the
-Mac OS X that causes process output to be truncated. To avoid this,
-leave process-connection-type set to its default value of nil.
-
-*** Mac OS X 10.3.9 (Carbon): QuickTime updater breaks build.
-
-Some QuickTime updaters such as 7.0.4 and 7.2.0 are known to break
-build at the link stage with the message like "Undefined symbols:
-_HICopyAccessibilityActionDescription referenced from QuickTime
-expected to be defined in Carbon". A workaround is to use a QuickTime
-reinstaller. Alternatively, you can link with the frameworks in the
-corresponding SDK by specifying LDFLAGS as
-"-Wl,-F/Developer/SDKs/MacOSX10.3.0.sdk/System/Library/Frameworks".
-
** FreeBSD
*** FreeBSD 2.1.5: useless symbolic links remain in /tmp or other
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
Supposedly the newer 32-bit version of this server doesn't have the
problem.
-** Known problems with the MS-Windows port of Emacs 22.1
+** Emacs crashes when opening a file with a UNC path and rails-mode is loaded.
+
+Loading rails-mode seems to interfere with UNC path handling. This has been
+reported as a bug against both Emacs and rails-mode, so look for an updated
+rails-mode that avoids this crash, or avoid using UNC paths if using
+rails-mode.
+
+** Known problems with the MS-Windows port of Emacs 22.3
+
+M-x term does not work on MS-Windows. TTY emulation on Windows is
+undocumented, and programs such as stty which are used on posix platforms
+to control tty emulation do not exist for native windows terminals.
Using create-fontset-from-ascii-font or the --font startup parameter
with a Chinese, Japanese or Korean font leads to display problems.
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
(using the location of the 32-bit X libraries on your system).
-*** Building the Cygwin port for MS-Windows can fail with some GCC versions
+*** Building Emacs for Cygwin can fail with GCC 3
+
+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.
+
+*** Building the native MS-Windows port fails due to unresolved externals
+
+The linker error messages look like this:
+
+ oo-spd/i386/ctags.o:ctags.c:(.text+0x156e): undefined reference to `_imp__re_set_syntax'
+ collect2: ld returned 1 exit status
+
+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.
+
** 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 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.
+ 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
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 CVS 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.
*** Fatal signal in the command temacs -l loadup inc dump.
This command is the final stage of building Emacs. It is run by the
-Makefile in the src subdirectory, or by build.com on VMS.
+Makefile in the src subdirectory.
It has been known to get fatal errors due to insufficient swapping
space available on the machine.
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__
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)
+ 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.)
that affect other programs besides `scoterm'. In particular, these
resources affect Emacs also:
- *Font: -*-helvetica-medium-r-*--12-*-p-*
- *Background: scoBackground
- *Foreground: scoForeground
+ *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
+ 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
--- 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 {
** 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:
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
This seems to be due to a GCC bug; it is fixed in GCC 2.8.1.
-** VMS: Compilation errors on VMS.
-
-You will get warnings when compiling on VMS because there are
-variable names longer than 32 (or whatever it is) characters.
-This is not an error. Ignore it.
-
-VAX C does not support #if defined(foo). Uses of this construct
-were removed, but some may have crept back in. They must be rewritten.
-
-There is a bug in the C compiler which fails to sign extend characters
-in conditional expressions. The bug is:
- char c = -1, d = 1;
- int i;
-
- i = d ? c : d;
-The result is i == 255; the fix is to typecast the char in the
-conditional expression as an (int). Known occurrences of such
-constructs in Emacs have been fixed.
-
** Vax C compiler bugs affecting Emacs.
You may get one of these problems compiling Emacs:
In the XCONS, etc., macros in lisp.h you must replace (a).u.val with
((a).u.val + coercedummy) where coercedummy is declared as int.
-This problem will not happen if the m-...h file for your type
-of machine defines NO_UNION_TYPE. That is the recommended setting now.
+This problem will only happen if USE_LISP_UNION_TYPE is manually
+defined in lisp.h.
*** C compilers lose on returning unions.
Most of the functions in GNU Emacs return type Lisp_Object, which is
defined as a union on some rare architectures.
-This problem will not happen if the m-...h file for your type
-of machine defines NO_UNION_TYPE.
+This problem will only happen if USE_LISP_UNION_TYPE is manually
+defined in lisp.h.
\f
This file is part of GNU Emacs.
-GNU Emacs is free software; you can redistribute it and/or modify
+GNU Emacs is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 3, or (at your option)
-any later version.
+the Free Software Foundation, either version 3 of the License, or
+(at your option) any later version.
GNU Emacs is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
-along with GNU Emacs; see the file COPYING. If not, write to the
-Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
-Boston, MA 02110-1301, USA.
+along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>.
\f
Local variables:
mode: outline
-paragraph-separate: "[ \f]*$"
+paragraph-separate: "[ \f]*$"
end:
arch-tag: 49fc0d95-88cb-4715-b21c-f27fb5a4764a
HCoop / bpt / emacs.git / blobdiff