XEmacs 21.4.20 No text on buttons, no root to hierachy, no help, no nothing...

[Stephen J. Turnbull]

The masked-coder known as Randux writes:

 > I'm not having any luck building XEmacs 21.4.20 (and getting it to
 > actually work) on Slackware with 2.6.17.13 kernel, gtk+1.2.10,
 > gtk+2.8.20 and gcc 3.4.6.

Try running ina terminal with "xemacs -nw", and using M-x
report-xemacs-bug to generate a bug report (and optionally send it, if
you have a sendmail compatible mailer).  If that generates a "no such
command" error, then as Glyn suggests you don't have the packages
installed where XEmacs can find them.

In that case, at least post whatever Installation file seems closest
to working, or is the one you would like to work.  It contains a fair
amount of information about your system (at least that part which is
visible to the XEmacs build system).

 > When I start XEmacs from a terminal I get a slew of messages saying
 > that there isn't an obvious root for the XEmacs hierarchy. The xemacs
 > executable is in /usr/local/bin and it is a symlink to the
 > versioned-executable.

ISTR that in XEmacs 21.4.19 there was a bug such that XEmacs expected
the packages to be in a particular place, and would complain about no
root if it didn't find them.  If you don't have the packages
installed, mkdir -p /usr/local/lib/xemacs/xemacs-packages, cd there,
download the "sumo" package from
ftp://ftp.xemacs.org/pub/xemacs/packages/, and untar the "sumo" there.
If you have built XEmacs with Mule support, you will also need the
Mule sumo.  (Do "dir *sumo*" or maybe "dir *SUMO*" in the packages
directory to find the exact names.)

 > (There is also a *.dmp in /usr/local/bin which
 > is quite hideous- is something broken or is that intentional?) The
 > libraries went into /usr/local/lib/xemacs-21.4.20/ 

No, that's the *fix*. :-)  That is the precompiled Lisp libraries that
have been turned into a memory image.  It reduces startup time for
xemacs -vanilla by about a factor of 20.  In 21.5 we've managed to
arrange that that file is actually stored in the binary, but this is
too tricky to backport to the stable line yet.

If it really offends you, feel free to risk the wrath of the SELinux
gods and the cacodaemons of the GNU toolchain and revert to the
traditional "unexec" method.  "./configure --pdump=no ..."  This is
likely to result in a binary that just segfaults immediately in many
"modern" environments, though.

Note also that GTK+ v2 is irrelevant to XEmacs; the GTK+ support has
never been ported from v1 to v2.