comparison etc/PROBLEMS @ 77139:8658cdd16704

Fix some typos.

77138:a97a103d97c7

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

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

77139:8658cdd16704

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

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