Merge from emacs-23 branch, up to 2010-05-20T22:16:19Z!juri@jurta.org.
[bpt/emacs.git] / etc / PROBLEMS
index 8c6a37d..7e856c1 100644 (file)
@@ -1,7 +1,7 @@
 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, 2009, 2010
+  2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011
   Free Software Foundation, Inc.
 See the end of the file for license conditions.
 
@@ -102,7 +102,7 @@ This can be another symptom of stale *.elc files in 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
+    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
@@ -235,19 +235,18 @@ necessary but missing, please report it via M-x report-emacs-bug.
 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).
+** When Emacs is compiled with Gtk+, closing a display kills Emacs.
 
-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.
+There is a long-standing bug in GTK that prevents it from recovering
+from disconnects: http://bugzilla.gnome.org/show_bug.cgi?id=85715.
 
-** Emacs compiled with Gtk+ may loop forever if a display crashes.
+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.
 
-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).
+If you need Emacs to be able to recover from closing displays, compile
+it with the Lucid toolkit instead of GTK.
 
 * General runtime problems
 
@@ -1037,7 +1036,7 @@ into Meta.  This is because of the great importance of Meta in Emacs.
 
 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 
+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".
@@ -1514,7 +1513,7 @@ 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.  On some systems, use
-"stty -ixon" instead. 
+"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
@@ -1661,6 +1660,19 @@ the script:
 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.
 
@@ -2339,17 +2351,18 @@ files are installed. Then use:
 
 (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 Emacs 23.3 and later will fail under Cygwin 1.5.19
+
+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 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).
+  http://lists.gnu.org/archive/html/emacs-devel/2010-07/msg01266.html
 
 *** Building the native MS-Windows port fails due to unresolved externals
 
@@ -2440,6 +2453,20 @@ several workarounds for 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
@@ -2733,7 +2760,7 @@ build Emacs in a directory on a local disk.
 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).
 
@@ -3230,5 +3257,3 @@ Local variables:
 mode: outline
 paragraph-separate: "[  \f]*$"
 end:
-
-arch-tag: 49fc0d95-88cb-4715-b21c-f27fb5a4764a