Fix TTY cursor reset problem

[sxemacs] / PROBLEMS.XEmacs

                                                  -*- mode:outline -*-

* XEmacs PROBLEMS file
======================

Following is a reproduction of the XEmacs PROBLEMS file, preserved for 
posterity. Many of the problems mentioned below have been fixed in 
SXEmacs (and in XEmacs). 

Note: Some irrelevant stuff purged (mostly windows rubbish) 2010-04-01

This file describes various problems that have been encountered
in compiling, installing and running XEmacs.  It has been updated for
XEmacs 21.5.

This file is rather large, but we have tried to sort the entries by
their respective relevance for XEmacs, but may have not succeeded
completely in that task.  The file is divided into four parts:

 - Problems with building XEmacs
 - Problems with running XEmacs
 - Compatibility problems
 - Mule issues

Use `C-c C-f' to move to the next equal level of outline, and
`C-c C-b' to move to previous equal level.  `C-h m' will give more
info about the Outline mode.

Also, Try finding the things you need using one of the search commands
XEmacs provides (e.g. `C-s').

General advice:

    WATCH OUT for your init file! (~/.xemacs/init.el or ~/.emacs)  If
    you observe strange problems, invoke XEmacs with the `-vanilla'
    option and see if you can repeat the problem.

    Note that most of the problems described here manifest at RUN
    time, even those described as BUILD problems.  It is quite unusual
    for a released XEmacs to fail to build.  So a "build problem"
    requires you to tweak the build environment, then rebuild XEmacs.
    A "runtime problem" is one that can be fixed by proper
    configuration of the existing build.  Compatibility problems and
    Mule issues are generally runtime problems, but are treated
    separately for convenience.


* Problems with building XEmacs
===============================

** General

    Much general information is in INSTALL.  If it's covered in
    INSTALL, we don't repeat it here.

*** How do I configure to get the buffer tabs/progress bars?

These features depend on support for "native widgets".  Use the
--with-widgets option to configure.  Configuration of widgets is
automatic for "modern" toolkits (MS Windows, GTK, and Motif), but if
you are using Xt and the Athena widgets, you will probably want to
specify a "3d" widget set.  See configure --usage, and don't forget to
install the corresponding development libraries.

*** I know I have libfoo installed, but configure doesn't find it.

Typical of Linux systems with package managers.  To link with a shared
library, you only need the shared library.  To compile objects that
link with it, you need the headers---and distros don't provide them with
the libraries.  You need the additional "development" package, too.

*** When using gcc, you get the error message "undefined symbol __fixunsdfsi".
When using gcc, you get the error message "undefined symbol __main".

This means that you need to link with the gcc library.  It may be called
"gcc-gnulib" or "libgcc.a"; figure out where it is, and define LIB_GCC in
config.h to point to it.

It may also work to use the GCC version of `ld' instead of the standard one.

*** src/Makefile and lib-src/Makefile are truncated--most of the file missing.

This can happen if configure uses GNU sed version 2.03.  That version
had a bug.  GNU sed version 2.05 works properly.

** Motif

Motif is the X11 version of the Gnus torture test: if there's a way to
crash, Motif will find it.  With the open source release of Motif, it
seems like a good idea to collect all Motif-related issues in one
place.

You should also look in your OS's section, as it may not be Motif's
fault.

*** XEmacs visibly repaints itty-bitty rectangles very slowly.

This should only be visible on a slow X connection (ISDN, maybe T1).

At least some versions of Motif apparently do not implement
XtExposeCompressMaximal properly, so it is disabled.  If you wish to
experiment, you can remove the #ifdef LWLIB_NEEDS_MOTIF at line 238
(or so) of src/EmacsFrame.c, leaving only the line

    /* compress_exposure        */      XtExposeCompressMaximal | XtExposeNoRegion,

and recompile.  This enables exposure compression, giving a 10:1 or
better speedup for some users.  However, on some Motif platforms (Red
Hat Linux 9.0 and Solaris 2.8, at least), this causes XEmacs to hang
while displaying the progress bar (eg, in font-lock).  A workaround
for that problem is to setq `progress-feedback-use-echo-area' to `t'.

*** XEmacs crashes on exit (#1).

The backtrace is something like:

    (gdb) where
    #0  0xfeb9a480 in _libc_kill () from /usr/lib/libc.so.1
    #1  0x000b0388 in fatal_error_signal ()
    #2  <signal handler called>
    #3  YowIter (ht=0xb, id=0x0, v=0x74682074, client=0x47e3c0)
        at ImageCache.c:1159
    #4  0xff26cc5c in _LTHashTableForEachItem (ht=0x4725e8,
        iter=0xff26dda0 <YowIter>, ClientData=0x47e3c0) at Hash.c:671
    #5  0xff2a4664 in destroy (w=0x496550) at Screen.c:352
    #6  0xfef92118 in Phase2Destroy () from /usr/openwin/lib/libXt.so.4
    #7  0xfef91940 in Recursive () from /usr/openwin/lib/libXt.so.4
    #8  0xfef91e44 in XtPhase2Destroy () from /usr/openwin/lib/libXt.so.4
    #9  0xfef91ae8 in _XtDoPhase2Destroy () from /usr/openwin/lib/libXt.so.4
    #10 0xfef918cc in XtDestroyWidget () from /usr/openwin/lib/libXt.so.4
    #11 0xfef91438 in CloseDisplay () from /usr/openwin/lib/libXt.so.4
    #12 0xfef91394 in XtCloseDisplay () from /usr/openwin/lib/libXt.so.4
    #13 0x0025b8b0 in x_delete_device ()
    #14 0x000940b0 in delete_device_internal ()
    #15 0x000806a0 in delete_console_internal ()

This is known to happen with Lesstif version 0.93.36.  Similar
backtraces have also been observed on HP/UX and Solaris.  There is a
patch for Lesstif.  (This is not a solution; it just stops the crash.
It may or may not be harmless, but "it works for the author".)

Note that this backtrace looks a lot like the one in the next item.
However, this one is invulnerable to the Solaris patches mentioned there.

Frank McIngvale <frankm@hiwaay.net> says:

    Ok, 0.93.34 works, and I tracked down the crash to a section
    marked "experimental" in 0.93.36. Patch attached, "works for me".

diff -u -r lesstif-0.93.36/lib/Xm/ImageCache.c lesstif-0.93.36-mod/lib/Xm/ImageCache.c
--- lesstif-0.93.36/lib/Xm/ImageCache.c 2002-08-05 14:53:24.000000000 -0500
+++ lesstif-0.93.36-mod/lib/Xm/ImageCache.c     2002-11-11 11:13:12.000000000 -0600
@@ -1166,5 +1166,4 @@
        DEBUGOUT(_LtDebug0(__FILE__, NULL, "_LtImageCacheScreenDestroy (XmGetPixmapByDepth) %p\n",
                s));
 
-       (void) _LTHashTableForEachItem(PixmapCache, YowIter, (XtPointer)s);
 }

*** XEmacs crashes on exit (#2)

Especially frequent with multiple frames.  Crashes that produce C
backtraces like this:

#0  0xfec9a118 in _libc_kill () from /usr/lib/libc.so.1
#1  0x77f48 in fatal_error_signal (sig=11)
    at /codes/rpluim/xemacs-21.4/src/emacs.c:539
#2  <signal handler called>
#3  0xfee929f4 in XFindContext () from /usr/openwin/lib/libX11.so.4
#4  0xfee92930 in XFindContext () from /usr/openwin/lib/libX11.so.4
#5  0xff297e54 in DisplayDestroy () from /usr/dt/lib/libXm.so.4
#6  0xfefbece0 in XtCallCallbackList () from /usr/openwin/lib/libXt.so.4
#7  0xfefc486c in XtPhase2Destroy () from /usr/openwin/lib/libXt.so.4
#8  0xfefc45d0 in _XtDoPhase2Destroy () from /usr/openwin/lib/libXt.so.4
#9  0xfefc43b4 in XtDestroyWidget () from /usr/openwin/lib/libXt.so.4
#10 0x15cf9c in x_delete_device (d=0x523f00)

are caused by buggy Motif libraries.  Installing the following patches
has been reported to solve the problem on Solaris 2.7:

107081-40 107656-07

For information (although they have not been confirmed to work), the
equivalent patches for Solaris 2.8 are:

108940-33 108652-25

*** On HP-UX 11.0 XEmacs causes excessive X11 errors when running.
    (also appears on AIX as reported in comp.emacs.xemacs)

Marcus Thiessel <marcus@xemacs.org>

  Unfortunately, XEmacs releases prior to 21.0 don't work with
  Motif2.1. It will compile but you will get excessive X11 errors like

  xemacs: X Error of failed request:  BadGC (invalid GC parameter)

  and finally XEmacs gets killed. A workaround is to use the
  Motif1.2_R6 libraries. You can the following line to your call to
  configure:

     --x-libraries="/usr/lib/Motif1.2_R6 -L/usr/lib/X11R6"

  Make sure /usr/lib/Motif1.2_R6/libXm.sl is a link to
  /usr/lib/Motif1.2_R6/libXm.3.

*** On HP-UX 11.0: Object "" does not have windowed ancestor

Marcus Thiessel <marcus@xemacs.org>

  XEmacs dies without core file and reports:

    Error: Object "" does not have windowed ancestor.

  This is a bug. Please apply the patch PHSS_19964 (check if
  superseded). The other alternative is to link with Motif1.2_R6 (see
  previous item).

*** Motif dialog boxes lose on Irix.

Larry Auton <lda@control.att.com> writes:
Beware of not specifying

        --with-dialogs=athena

if it builds with the motif dialogs [boom!] you're a dead man.


** AIX
*** IBM compiler fails: "The character # is not a valid C source character."

Most recently observed in 21.5.9, due to USE_KKCC ifdefs (they just
happen to tickle the implementation).

Valdis Kletnieks says:

  The problem is that IBM defines a *MACRO* called 'memcpy', and we
  have stuck a #ifdef/#endif inside the macro call.  As a workaround,
  try adding '-U__STR__' to your CFLAGS - this will cause string.h to
  not do a #define for strcpy() to __strcpy() - it uses this for
  automatic inlining support.

  (For the record, the same issue affects a number of other functions
  defined in string.h - basically anything the compiler knows how to
  inline.)

*** On AIX 4.3, you must specify --with-dialogs=athena with configure

*** The libXt shipped with AIX 4.3 up to 4.3.2 is broken.  This causes
    xemacs -nw to fail in various ways.  The official APAR is this:

APAR NUMBER: <IX89470>            RESOLVED AS: PROGRAM ERROR

ABSTRACT:
<IX89470>: LIBXT.A INCORRECT HANDLING OF EXCEPTIONS IN XTAPPADDINPUT

    The solution is to install X11.base.lib at version >=4.3.2.5.

*** On AIX, you get this compiler error message:

    Processing include file ./XMenuInt.h
        1501-106: (S) Include file X11/Xlib.h not found.

This means your system was installed with only the X11 runtime i.d
libraries.  You have to find your sipo (bootable tape) and install
X11Dev... with smit.

*** On AIX 4.1.2, linker error messages such as
   ld: 0711-212 SEVERE ERROR: Symbol .__quous, found in the global symbol table
         of archive /usr/lib/libIM.a, was not defined in archive member shr.o.

This is a problem in libIM.a.  You can work around it by executing
these shell commands in the src subdirectory of the directory where
you build Emacs:

    cp /usr/lib/libIM.a .
    chmod 664 libIM.a
    ranlib libIM.a

Then change -lIM to ./libIM.a in the command to link temacs (in
Makefile).

*** Excessive optimization on AIX 4.2 can lead to compiler failure.

Valdis.Kletnieks@vt.edu writes:
  At least at the b34 level, and the latest-and-greatest IBM xlc
  (3.1.4.4), there are problems with -O3.  I haven't investigated
  further.


** SunOS/Solaris
*** Dumping error when using GNU binutils / GNU ld on a Sun.

Errors similar to the following:

   Dumping under the name xemacs unexec():
   dldump(/space/rpluim/xemacs-obj/src/xemacs): ld.so.1: ./temacs:
   fatal: /space/rpluim/xemacs-obj/src/xemacs: unknown dynamic entry:
   1879048176

are caused by using GNU ld.  There are several workarounds available:

In XEmacs 21.2 or later, configure using the new portable dumper
(--pdump).

Alternatively, you can link using the Sun version of ld, which is
normally held in /usr/ccs/bin.  This can be done by one of:

- building gcc with these configure flags:
  configure --with-ld=/usr/ccs/bin/ld --with-as=/usr/ccs/bin/as

- adding -B/usr/ccs/bin/ to CFLAGS used to configure XEmacs
  (Note: The trailing '/' there is significant.)

- uninstalling GNU ld.

The Solaris2 FAQ claims:

    When you install gcc, don't make the mistake of installing
    GNU binutils or GNU libc, they are not as capable as their
    counterparts you get with Solaris 2.x.

*** Link failure when using acc on a Sun.

To use acc, you need additional options just before the libraries, such as

   /usr/lang/SC2.0.1/values-Xt.o -L/usr/lang/SC2.0.1/cg87 -L/usr/lang/SC2.0.1

and you need to add -lansi just before -lc.

The precise file names depend on the compiler version, so we
cannot easily arrange to supply them.

*** Problems finding X11 libraries on Solaris with Openwindows

Some users have reported problems in this area.  The reported solution
is to define the environment variable OPENWINHOME, even if you must set
it to `/usr/openwin'.

*** Sed problems on Solaris 2.5

There have been reports of Sun sed truncating very lines in the
Makefile during configuration.  The workaround is to use GNU sed or,
even better, think of a better way to generate Makefile, and send us a
patch. :-)

*** On Solaris 2 I get undefined symbols from libcurses.a.

You probably have /usr/ucblib/ on your LD_LIBRARY_PATH.  Do the link with
LD_LIBRARY_PATH unset.  Generally, avoid using any ucb* stuff when
building XEmacs.

*** On Solaris 2 I cannot make alloc.o, glyphs.o or process.o.

The SparcWorks C compiler may have difficulty building those modules
with optimization level -xO4.  Try using only "-fast" optimization
for just those modules.  (Or use gcc).

*** Solaris 2.3 /bin/sh coredumps during configuration.

This only occurs if you have LANG != C.  This is a known bug with
/bin/sh fixed by installing Patch-ID# 101613-01.  Or, you can use
bash by setting the environment variable CONFIG_SHELL to /bin/bash

*** Solaris 2.x configure/Makefile syntax "errors"

This is a known bug with /bin/sh and /bin/test, i.e. they do not
support the XPG4 standard.  You can use bash as a workaround or an
XPG4-compliant Bourne shell such as the Sun-supplied /usr/xpg4/bin/sh
by setting the environment variable CONFIG_SHELL to /usr/xpg4/bin/sh

*** On SunOS, you get linker errors
    ld: Undefined symbol
       _get_wmShellWidgetClass
       _get_applicationShellWidgetClass

The fix to this is to install patch 100573 for OpenWindows 3.0
or link libXmu statically.

*** On Sunos 4, you get the error ld: Undefined symbol __lib_version.

This is the result of using cc or gcc with the shared library meant
for acc (the Sunpro compiler).  Check your LD_LIBRARY_PATH and delete
/usr/lang/SC2.0.1 or some similar directory.

*** Undefined symbols when linking on Sunos 4.1.

If you get the undefined symbols _atowc _wcslen, _iswprint, _iswspace,
_iswcntrl, _wcscpy, and _wcsncpy, then you need to add -lXwchar after
-lXaw in the command that links temacs.

This problem seems to arise only when the international language
extensions to X11R5 are installed.

*** On a Sun running SunOS 4.1.1, you get this error message from GNU ld:

    /lib/libc.a(_Q_sub.o): Undefined symbol __Q_get_rp_rd referenced from text segment

The problem is in the Sun shared C library, not in GNU ld.

The solution is to install Patch-ID# 100267-03 from Sun.

*** SunOS 4.1.2: undefined symbol _get_wmShellWidgetClass

  Apparently the version of libXmu.so.a that Sun ships is hosed: it's missing
  some stuff that is in libXmu.a (the static version).  Sun has a patch for
  this, but a workaround is to use the static version of libXmu, by changing
  the link command from "-lXmu" to "-Bstatic -lXmu -Bdynamic".  If you have
  OpenWindows 3.0, ask Sun for these patches:
    100512-02       4.1.x OpenWindows 3.0 libXt Jumbo patch
    100573-03       4.1.x OpenWindows 3.0 undefined symbols with shared libXmu

*** Random other SunOS 4.1.[12] link errors.

  The X headers and libraries that Sun ships in /usr/{include,lib}/X11 are
  broken.  Use the ones in /usr/openwin/{include,lib} instead.

** Linux

See also Intel Architecture General, above.

*** Under Linux, you get "too many arguments to function `getpgrp'".

You have probably installed LessTiff under `/usr/local' and `libXm.so'
could not be found when linking `getpgrp()' test program, making XEmacs
think that `getpgrp()' takes an argument. Try adding `/usr/local/lib'
in `/etc/ld.so.conf' and run `ldconfig'. Then run XEmacs's `configure'
again.  As with all problems of this type, reading the config.log file
generated from configure and seeing the log of how the test failed can
prove enlightening.

*** `Error: No ExtNode to pop!' on Linux systems with Lesstif.

This error message has been observed with lesstif-0.75a.  It does not
appear to cause any harm.

** IRIX

*** More coredumping in Irix (6.5 known to be vulnerable)

No fix is known yet.  Here's the best information we have:

Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes:

  Were xemacs and [any 3rd party, locally-compiled] libraries [you use]
  all compiled with the same ABI ( -o32, -n32, -64) and
  mips2/mips3/mips4 flags, and are they appropriate for the machine in
  question?  I know the IP30 implies an Octane, so it should be an R10K
  chipset and above such nonsense, but I've seen the most astoundingly
  bizzare crashes when somebody managed to compile with -mips4 and get
  it to run on an R4400 or R5K system. ;)

  Also, since you're using gcc, try re-running fixincludes and *then*
  rebuilding xemacs and [any] libraries - mismatched headers can do that
  sort of thing to you with little or no clue what's wrong (often you
  get screwed when one routine does an malloc(sizeof(foo_struct)) and
  passes the result to something that things foo_struct is a bit bigger,
  trashing memory..