Known Problems with GNU Emacs
-Copyright (C) 1987-1989, 1993-1999, 2001-2014 Free Software Foundation, Inc.
+Copyright (C) 1987-1989, 1993-1999, 2001-2015 Free Software Foundation,
+Inc.
See the end of the file for license conditions.
"localhost.localdomain", rather the name you were expecting.
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.
+(i.e., a name with at least one "."), either in /etc/hostname
+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.
endif
endif
-*** Emacs startup on GNU/Linux systems (and possibly other systems) is slow.
-
-This can happen if the system is misconfigured and Emacs can't get the
-full qualified domain name, FQDN. You should have your FQDN in the
-/etc/hosts file, something like this:
-
-127.0.0.1 localhost
-129.187.137.82 nuc04.t30.physik.tu-muenchen.de nuc04
-
-The way to set this up may vary on non-GNU systems.
-
*** Attempting to visit remote files via ange-ftp fails.
If the error message is "ange-ftp-file-modtime: Specified time is not
by another key (e.g. C-\) by modifying ~/.fcitx/config, or be
accustomed to use C-@ for `set-mark-command'.
+*** Link-time optimization with clang doesn't work on Fedora 20.
+
+As of May 2014, Fedora 20 has broken LLVMgold.so plugin support in clang
+(tested with clang-3.4-6.fc20) - `clang --print-file-name=LLVMgold.so'
+prints `LLVMgold.so' instead of full path to plugin shared library, and
+`clang -flto' is unable to find the plugin with the following error:
+
+/bin/ld: error: /usr/bin/../lib/LLVMgold.so: could not load plugin library:
+/usr/bin/../lib/LLVMgold.so: cannot open shared object file: No such file
+or directory
+
+The only way to avoid this is to build your own clang from source code
+repositories, as described at http://clang.llvm.org/get_started.html.
+
*** M-SPC seems to be ignored as input.
See if your X server is set up to use this as a command
When you start Emacs you may see something like this:
-(emacs:2286): LIBDBUSMENU-GTK-CRITICAL **: watch_submenu: assertion
+(emacs:2286): LIBDBUSMENU-GTK-CRITICAL **: watch_submenu: assertion
`GTK_IS_MENU_SHELL(menu)' failed
This happens if the Emacs binary has been renamed. The cause is the Ubuntu
** Emacs crashes when exiting the Emacs session
This was reported to happen when some optional DLLs, such as those
-used for displaying images or the GnuTLS library, which are loaded
-on-demand, have a runtime dependency on the libgcc DLL,
-libgcc_s_dw2-1.dll. The reason seems to be a bug in libgcc which
-rears its ugly head whenever the libgcc DLL is loaded after Emacs has
-started.
+used for displaying images or the GnuTLS library or zlib compression
+library, which are loaded on-demand, have a runtime dependency on the
+libgcc DLL, libgcc_s_dw2-1.dll. The reason seems to be a bug in
+libgcc which rears its ugly head whenever the libgcc DLL is loaded
+after Emacs has started.
One solution for this problem is to find an alternative build of the
same optional library that does not depend on the libgcc DLL.
(The -R option disables address space randomization.)
-*** test-distrib says that the distribution has been clobbered.
-*** or, temacs prints "Command key out of range 0-127".
-*** or, temacs runs and dumps emacs, but emacs totally fails to work.
-*** or, temacs gets errors dumping emacs.
-
-This can be because the .elc files have been garbled. Do not be
-fooled by the fact that most of a .elc file is text: these are
-binary files and can contain all 256 byte values.
-
-If you have a copy of Emacs whose .elc files have been damaged in this
-way, you should be able to fix it by using:
-
- make bootstrap
-
-to regenerate all the .elc files.
-
*** temacs prints "Pure Lisp storage exhausted".
This means that the Lisp code loaded from the .elc and .el files during
This is due to a bug in the bcopy implementation in openSUSE 10.3.
It is/will be fixed in an openSUSE update.
-** Installation
-
-*** On Solaris, use GNU Make when installing an out-of-tree build
-
-The Emacs configuration process allows you to configure the
-build environment so that you can build emacs in a directory
-outside of the distribution tree. When installing Emacs from an
-out-of-tree build directory on Solaris, you may need to use GNU
-make. The make programs bundled with Solaris support the VPATH
-macro but use it differently from the way the VPATH macro is
-used by GNU make. The differences will cause the "make install"
-step to fail, leaving you with an incomplete emacs
-installation. GNU make is available in /usr/sfw/bin on Solaris
-10 and can be installed as /opt/sfw/bin/gmake from the Solaris 9
-Software Companion CDROM.
-
-The problems due to the VPATH processing differences affect only
-out of tree builds so, if you are on a Solaris installation
-without GNU make, you can install Emacs completely by installing
-from a build environment using the original emacs distribution tree.
-
** First execution
*** Emacs binary is not in executable format, and cannot be run.
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-DOS if DJGPP v2.0 is used to compile Emacs.
-
-There are two DJGPP library bugs which cause problems:
-
- * Running `shell-command' (or `compile', or `grep') you get
- `Searching for program: permission denied (EACCES), c:/command.com';
- * After you shell to DOS, Ctrl-Break kills Emacs.
-
-To work around these bugs, you can use two files in the msdos
-subdirectory: `is_exec.c' and `sigaction.c'. Compile them and link
-them into the Emacs executable `temacs'; then they will replace the
-incorrect library functions.
-
*** MS-DOS: Emacs compiled for MSDOS cannot find some Lisp files, or other
run-time support files, when long filename support is enabled.