]> code.delx.au - gnu-emacs/blobdiff - etc/PROBLEMS
Merge from emacs-24; up to 2012-12-23T17:06:58Z!eliz@gnu.org
[gnu-emacs] / etc / PROBLEMS
index 078352d78f4a24f69e51f3d6797e2d8291c01f4f..b38a1240540f580a490e564ebb40c760930a89e1 100644 (file)
@@ -1,7 +1,7 @@
 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.
 
 
@@ -255,6 +255,36 @@ result in an endless loop.
 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
@@ -358,7 +388,7 @@ There are two different protocols in general use.  One of them uses
 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!
 
@@ -402,21 +432,7 @@ The fix is to install an unshared library that corresponds to what you
 installed in the shared library, and then relink Emacs.
 
 If you have already installed the name resolver in the file libresolv.a,
-then you need to compile Emacs to use that library.  The easiest way to
-do this is to add to config.h a definition of LIBS_SYSTEM, LIBS_MACHINE
-or LIB_STANDARD which uses -lresolv.  Watch out!  If you redefine a macro
-that is already in use in your configuration to supply some other libraries,
-be careful not to lose the others.
-
-Thus, you could start by adding this to config.h:
-
-#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:
-
-#define LIBS_SYSTEM -lresolv -lfoo -lbar
+then you need to compile Emacs to use that library.
 
 *** Emacs does not know your host's fully-qualified domain name.
 
@@ -1854,8 +1870,8 @@ Emacs uses symbolic links to implement file locks.  In a directory
 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.
 
@@ -2874,10 +2890,6 @@ 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 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
@@ -3153,58 +3165,6 @@ as a concentrator.
 
 This problem seems to be a matter of configuring the DECserver to use
 7 bit characters rather than 8 bit characters.
-
-* Build problems on legacy systems
-
-** SunOS: Emacs gets error message from linker on Sun.
-
-If the error message says that a symbol such as `f68881_used' or
-`ffpa_used' or `start_float' is undefined, this probably indicates
-that you have compiled some libraries, such as the X libraries,
-with a floating point option other than the default.
-
-It's not terribly hard to make this work with small changes in
-crt0.c together with linking with Fcrt1.o, Wcrt1.o or Mcrt1.o.
-However, the easiest approach is to build Xlib with the default
-floating point option: -fsoft.
-
-** HPUX 10.20: Emacs crashes during dumping on the HPPA machine.
-
-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.