comparison etc/PROBLEMS @ 90813:e6fdae9180d4

Merge from emacs--devo--0 Patches applied: * emacs--devo--0 (patch 698-710) - Update from CVS - Merge from gnus--rel--5.10 * gnus--rel--5.10 (patch 216) - Update from CVS Revision: [e-mail]/emacs--unicode--0--patch-196

90812:6137cc8ddf90

** Emacs compiled with Gtk+ crashes when closing a display (x-close-connection).

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 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.

* General runtime problems

** Lisp problems

#define LIBS_SYSTEM -lresolv -lfoo -lbar

*** Emacs does not know your host's fully-qualified domain name.

You need to configure your machine with a fully qualified domain name,
either in /etc/hosts, /etc/hostname, the NIS, 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.

** NFS and RFS

The problems seem to depend on the version of LessTif and the Motif
emulation for which it is set up.

Only the Motif 1.2 emulation seems to be stable enough in LessTif.
Lesstif 0.92-17's Motif 1.2 emulation seems to work okay on FreeBSD.
On GNU/Linux systems, lesstif-0.92.6 configured with "./configure
--enable-build-12 --enable-default-12" is reported to be the most
successful.  The binary GNU/Linux package
lesstif-devel-0.92.0-1.i386.rpm was reported to have problems with
menu placement.

4) Use lbxproxy on the remote end of the connection.  This is an interface
   to the low bandwidth X extension in most modern X servers, which
   improves performance dramatically, at the slight expense of correctness
   of the X protocol.  lbxproxy acheives the performance gain by grouping
   several X requests in one TCP packet and sending them off together,
   instead of requiring a round-trip for each X request in a seperate
   packet.  The switches that seem to work best for emacs are:
    -noatomsfile  -nowinattr  -cheaterrors -cheatevents
   Note that the -nograbcmap option is known to cause problems.
   For more about lbxproxy, see:
   http://www.xfree86.org/4.3.0/lbxproxy.1.html

  (setq x-sigio-bug t)

in your site-init.el file.

* Runtime problems on character termunals

** Emacs spontaneously displays "I-search: " at the bottom of the screen.

This means that Control-S/Control-Q (XON/XOFF) "flow control" is being
used.  C-s/C-q flow control is bad for Emacs editors because it takes

** Compilation

*** Building Emacs over NFS fails with ``Text file busy''.

This was reported to happen when building Emacs on a GNU/Linux system
(RedHat Linux 6.2) using a build directory automounted from Solaris
(SunOS 5.6) file server, but it might not be limited to that
configuration alone.  Presumably, the NFS server doesn't commit the
files' data to disk quickly enough, and the Emacs executable file is
left ``busy'' for several seconds after Emacs has finished dumping
itself.  This causes the subsequent commands which invoke the dumped

  env CC="gcc -m32" ./configure --build=i386-linux-gnu \
    --x-libraries=/usr/X11R6/lib

(using the location of the 32-bit X libraries on your system).

*** Building the Cygwin port for MS-Windows can fail with some GCC version

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.1.1, and 4.1.2 reportedly
build a working Cygwin binary of Emacs, so we recommend these GCC
versions.  Note that these three versions of GCC, 4.0.3, 4.1.1, and
4.1.2, are currently the _only_ versions known to succeed in building
Emacs (as of v22.1).

*** Building the native MS-Windows port with Cygwin GCC can fail.

Emacs may not build using recent Cygwin builds of GCC, such as Cygwin
version 1.1.8, using the default configure settings.  It appears to be

** Dumping

*** Linux: Segfault during `make bootstrap' under certain recent versions of the Linux kernel.

With certain recent Linux kernels (like the one of Redhat Fedora Core
1 and newer), the new "Exec-shield" functionality is enabled by default, which
creates a different memory layout that breaks the emacs dumper.  Emacs tries
to handle this at build time, but if the workaround used fails, these
instructions can be useful.
The work-around explained here is not enough on Fedora Core 4 (and possible

90813:e6fdae9180d4

** Emacs compiled with Gtk+ crashes when closing a display (x-close-connection).

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 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.

* General runtime problems

** Lisp problems

#define LIBS_SYSTEM -lresolv -lfoo -lbar

*** Emacs does not know your host's fully-qualified domain name.

For example, (system-name) returns some variation on
"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.

If you cannot fix the configuration, you can set the Lisp variable
mail-host-address to the value you want.

** NFS and RFS

The problems seem to depend on the version of LessTif and the Motif
emulation for which it is set up.

Only the Motif 1.2 emulation seems to be stable enough in LessTif.
LessTif 0.92-17's Motif 1.2 emulation seems to work okay on FreeBSD.
On GNU/Linux systems, lesstif-0.92.6 configured with "./configure
--enable-build-12 --enable-default-12" is reported to be the most
successful.  The binary GNU/Linux package
lesstif-devel-0.92.0-1.i386.rpm was reported to have problems with
menu placement.

4) Use lbxproxy on the remote end of the connection.  This is an interface
   to the low bandwidth X extension in most modern X servers, which
   improves performance dramatically, at the slight expense of correctness
   of the X protocol.  lbxproxy acheives the performance gain by grouping
   several X requests in one TCP packet and sending them off together,
   instead of requiring a round-trip for each X request in a separate
   packet.  The switches that seem to work best for emacs are:
    -noatomsfile  -nowinattr  -cheaterrors -cheatevents
   Note that the -nograbcmap option is known to cause problems.
   For more about lbxproxy, see:
   http://www.xfree86.org/4.3.0/lbxproxy.1.html

  (setq x-sigio-bug t)

in your site-init.el file.

* Runtime problems on character terminals

** Emacs spontaneously displays "I-search: " at the bottom of the screen.

This means that Control-S/Control-Q (XON/XOFF) "flow control" is being
used.  C-s/C-q flow control is bad for Emacs editors because it takes

** Compilation

*** Building Emacs over NFS fails with ``Text file busy''.

This was reported to happen when building Emacs on a GNU/Linux system
(Red Hat Linux 6.2) using a build directory automounted from Solaris
(SunOS 5.6) file server, but it might not be limited to that
configuration alone.  Presumably, the NFS server doesn't commit the
files' data to disk quickly enough, and the Emacs executable file is
left ``busy'' for several seconds after Emacs has finished dumping
itself.  This causes the subsequent commands which invoke the dumped

  env CC="gcc -m32" ./configure --build=i386-linux-gnu \
    --x-libraries=/usr/X11R6/lib

(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 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).

*** Building the native MS-Windows port with Cygwin GCC can fail.

Emacs may not build using recent Cygwin builds of GCC, such as Cygwin
version 1.1.8, using the default configure settings.  It appears to be

** Dumping

*** Linux: Segfault during `make bootstrap' under certain recent versions of the Linux kernel.

With certain recent Linux kernels (like the one of Red Hat Fedora Core
1 and newer), the new "Exec-shield" functionality is enabled by default, which
creates a different memory layout that breaks the emacs dumper.  Emacs tries
to handle this at build time, but if the workaround used fails, these
instructions can be useful.
The work-around explained here is not enough on Fedora Core 4 (and possible