xemacs 21.[45] on sparc64?

[Hauke Fath <hf%spg.tu-darmstadt.de@localhost>]

Hi,

what are your experiences with running xemacs on sparc64?

I set up an Ultra 1 with NetBSD 4 recently, and have issues with both 
the xemacs 21.4 and 21.5 packages.

21.5 comes up ( X or no X) with a bogus

[hf@Gurgler] ~ > xemacs -vanilla

WARNING:
Couldn't find obvious defaults for:
doc-directory
exec-directory
Perhaps some directories don't exist, or the XEmacs executable,
/usr/pkg/bin/xemacs
is in a strange place?

<continues after a keypress>

[hf@Gurgler] ~ >

21.4 works fine non-x ("xemacs -nw"), but dumps core with X:

[...]

Lisp backtrace follows:

  # (unwind-protect ...)
  # (catch #<INTERNAL OBJECT (XEmacs bug?) (opaque-ptr, adr=0x3e5b28) 
0x412620> ...)
  # (unwind-protect ...)
  # bind (inhibit-quit frame-being-created)
  make-frame(nil #<x-device on "localhost:12.0" 0x28fc>)
  frame-initialize()
  # bind (debugger debug-on-error command-line-args-left)
  command-line()
  # (condition-case ... . ((t (byte-code "      §" ... 1))))
  # bind (error-data)
  normal-top-level()
  # (condition-case ... . error)
  # (catch top-level ...)
Segmentation fault(core dumped)
[hf@Gurgler] ~ > gdb /usr/pkg/bin/xemacs xemacs-21.4.17.core
GNU gdb 6.5

[...]

Core was generated by `xemacs-21.4.17'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000000000177d3c in fatal_error_signal ()
(gdb) where
#0  0x0000000000177d3c in fatal_error_signal ()
#1  <signal handler called>
#2  0x0000000000000600 in ?? ()
#3  0xffffffffffff9b98 in ?? ()
Previous frame identical to this frame (corrupt stack?)
(gdb)

Is this just bit rot in xemacs (and, more, in the xemacs packages), or a 
sparc64 problem?

        hauke

--
     The ASCII Ribbon Campaign                    Hauke Fath
()     No HTML/RTF in email             Institut für Nachrichtentechnik
/\     No Word docs in email                     TU Darmstadt
     Respect for open standards              Ruf +49-6151-16-3281