Known Problems with GNU Emacs
-Copyright (C) 1987-1989, 1993-1999, 2001-2012
- Free Software Foundation, Inc.
+Copyright (C) 1987-1989, 1993-1999, 2001-2013 Free Software Foundation,
+Inc.
See the end of the file for license conditions.
If you need Emacs to be able to recover from closing displays, compile
it with the Lucid toolkit instead of GTK.
+** Emacs crashes when you try to view a file with complex characters.
+For example, the etc/HELLO file (as shown by C-h h).
+The message "symbol lookup error: /usr/bin/emacs: undefined symbol: OTF_open"
+is shown in the terminal from which you launched Emacs.
+This problem only happens when you use a graphical display (ie not
+with -nw) and compiled Emacs with the "libotf" library for complex
+text handling.
+
+This problem occurs because unfortunately there are two libraries
+called "libotf". One is the library for handling OpenType fonts,
+http://www.m17n.org/libotf/, which is the one that Emacs expects.
+The other is a library for Open Trace Format, and is used by some
+versions of the MPI message passing interface for parallel
+programming.
+
+For example, on RHEL6 GNU/Linux, the OpenMPI rpm provides a version
+of "libotf.so" in /usr/lib/openmpi/lib. This directory is not
+normally in the ld search path, but if you want to use OpenMPI,
+you must issue the command "module load openmpi". This adds
+/usr/lib/openmpi/lib to LD_LIBRARY_PATH. If you then start Emacs from
+the same shell, you will encounter this crash.
+Ref: <URL:https://bugzilla.redhat.com/show_bug.cgi?id=806031>
+
+There is no good solution to this problem if you need to use both
+OpenMPI and Emacs with libotf support. The best you can do is use a
+wrapper shell script (or function) "emacs" that removes the offending
+element from LD_LIBRARY_PATH before starting emacs proper.
+Or you could recompile Emacs with an -Wl,-rpath option that
+gives the location of the correct libotf.
+
* General runtime problems
** Lisp problems
the `flock' system call. The other involves creating a lock file;
`movemail' must be able to write in /usr/spool/mail in order to do
this. You control which one is used by defining, or not defining,
-the macro MAIL_USE_FLOCK in config.h or the m/ or s/ file it includes.
+the macro MAIL_USE_FLOCK in config.h.
IF YOU DON'T USE THE FORM OF INTERLOCKING THAT IS NORMAL ON YOUR
SYSTEM, YOU CAN LOSE MAIL!
#define LIBS_SYSTEM -lresolv
Then if this gives you an error for redefining a macro, and you see that
-the s- file defines LIBS_SYSTEM as -lfoo -lbar, you could change config.h
-again to say this:
+config.h already defines LIBS_SYSTEM as -lfoo -lbar at some other point
+(possibly in an included file) you could change it to say this:
#define LIBS_SYSTEM -lresolv -lfoo -lbar
with +t bit, the directory owner becomes the owner of the symbolic
link, so that it cannot be removed by anyone else.
-If you don't like those useless links, you can let Emacs not to using
-file lock by adding #undef CLASH_DETECTION to config.h.
+If you don't like those useless links, you can customize
+the option `create-lockfiles'.
*** FreeBSD: Getting a Meta key on the console.
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 10: Large file support is disabled.
-(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.
This happens if you use the MIT versions of the X libraries--it
This seems to be due to a GCC bug; it is fixed in GCC 2.8.1.
-** Vax C compiler bugs affecting Emacs.
-
-You may get one of these problems compiling Emacs:
-
- foo.c line nnn: compiler error: no table entry for op STASG
- foo.c: fatal error in /lib/ccom
-
-These are due to bugs in the C compiler; the code is valid C.
-Unfortunately, the bugs are unpredictable: the same construct
-may compile properly or trigger one of these bugs, depending
-on what else is in the source file being compiled. Even changes
-in header files that should not affect the file being compiled
-can affect whether the bug happens. In addition, sometimes files
-that compile correctly on one machine get this bug on another machine.
-
-As a result, it is hard for me to make sure this bug will not affect
-you. I have attempted to find and alter these constructs, but more
-can always appear. However, I can tell you how to deal with it if it
-should happen. The bug comes from having an indexed reference to an
-array of Lisp_Objects, as an argument in a function call:
- Lisp_Object *args;
- ...
- ... foo (5, args[i], ...)...
-putting the argument into a temporary variable first, as in
- Lisp_Object *args;
- Lisp_Object tem;
- ...
- tem = args[i];
- ... foo (r, tem, ...)...
-causes the problem to go away.
-The `contents' field of a Lisp vector is an array of Lisp_Objects,
-so you may see the problem happening with indexed references to that.
-
\f
This file is part of GNU Emacs.