Two problems with the xemacs 21.4.15-r2 sources makes it fail to emerge on my ia64 machine: 1) src/lisp.h:262 defines the symbol 'register' to the empty value. This conflicts with linux/ia64 system header files (eg <asm/gcc_intrin.h:27>): register unsigned long ia64_r13 asm ("r13") __attribute_used__; gcc -c -O2 -pipe -Demacs -I. -DHAVE_CONFIG_H -I/usr/X11R6/include gpmevent.c In file included from /usr/include/asm/intrinsics.h:19, from /usr/include/asm/processor.h:18, from /usr/include/linux/prefetch.h:15, from /usr/include/linux/list.h:5, from /usr/include/linux/wait.h:12, from /usr/include/linux/keyboard.h:4, from gpmevent.c:48: /usr/include/asm/gcc_intrin.h:27: error: register name given for non-register variable `ia64_r13' 2) If the above problem is patched, the next problem that strikes is that the global variable 'lim_data' which is used from src/vm-limit.c:check_memory_limits(), is: * Declared as an unsigned int, and thus can't hold the full range of an LP64 system. size_t whould be a better choice. * Even if 'lim_data' is declared as size_t, get_lim_data() sets it too a much too small value (fprintf in src/vm-limit.c:check_memory_limits()): ./xemacs -nd -batch -l /var/tmp/portage/xemacs-21.4.15-r2/work/xemacs-21.4.15/src/../lisp/update-elc.el xemacs(22122): unaligned access to 0x6000000000023a9c, ip=0x400000000031a181 xemacs(22122): unaligned access to 0x6000000000023a9c, ip=0x400000000031a110 xemacs(22122): unaligned access to 0x6000000000023a9c, ip=0x400000000031a150 xemacs(22122): unaligned access to 0x6000000000023a9c, ip=0x400000000031a521 lim_data: 0x00000000ff1fb8e7 cp: 0x60000000001a4000 data_space_start: 0x2000000000e04718 data_size: 0x00000000ff39f8e8 lim_data: 0x00000000ff1fb8e7 cp: 0x60000000001c8000 data_space_start: 0x2000000000e04718 data_size: 0x00000000ff3c38e8 lim_data: 0x00000000ff1fb8e7 cp: 0x60000000001ec000 data_space_start: 0x2000000000e04718 data_size: 0x00000000ff3e78e8 make: *** [update-elc.stamp] Segmentation fault * Since 'lim_data' and/or 'data_space_start' are too small, src/vm-limit.c:check_memory_limits() triggers before the xemacs runtime is fully initialized, and the resulting xemacs binary dumps core. Reproducible: Always Steps to Reproduce: 1. emerge xemacs Actual Results: emerge compiles for a while, and fails on gpmevent.c as above. Expected Results: It should have compiled and installed a working xemacs binary. # emerge info Portage 2.0.51-r3 (default-linux/ia64/2004.3, gcc-3.3.2, glibc-2.3.2-r12, 2.6.8-gentoo-r3 ia64) ================================================================= System uname: 2.6.8-gentoo-r3 ia64 Gentoo Base System version 1.4.16 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.14.90.0.8-r1 Headers: sys-kernel/linux26-headers-2.6.8.1,sys-kernel/linux26-headers-2.6.8.1-r1 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="ia64" AUTOCLEAN="yes" CFLAGS="-O2 -pipe" CHOST="ia64-unknown-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://gentoo.osuosl.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acpi berkdb bitmap-fonts bzlib canna cjk crypt cups emacs encode f77 foomaticdb fortran freetds gdbm gif gmp gnutls gpm gtk gtk2 ia64 imlib ipv6 jpeg libg++ libwww maildir mbox mhash mikmod mime motif mule multilib mysql mysqli ncurses nis nls nptl odbc offensive oggvorbis opengl oss pam pcre pdflib perl pic pie png posix python qt quicktime readline recode samba sdl spell sqlite ssl tcpd tiff truetype unicode xml2 xmms xpm xv zlib"
Looking through the source code it seems that the first issue has not yet been fixed, but the second might be. At least lim_data is now defined to be unsigned long. It would be great if you could verify the current status with xemacs 21.4.19. I'll bring up this bug on the XEmacs beta mailing list.
The people on the xemacs-beta list think that this hack would solve (or rather work around) the problem. Could you verify this so? cvsroot/xemacs-21.4 Mon 11 12:39; diff -u src/gpmevent.c{~,} --- src/gpmevent.c~ 2001-04-12 14:23:53.000000000 -0400 +++ src/gpmevent.c 2006-12-11 12:39:17.472975500 -0500 @@ -45,6 +45,7 @@ #define KG_CTRL 2 #define KG_ALT 3 #else +#undef register #include <linux/keyboard.h> #endif
The current xemacs (xemacs-21.4.17) emerges ok. The resulting binary does however still dump core: $ xemacs -nw Fatal error (11). Your files have been auto-saved. Use `M-x recover-session' to recover them. Your version of XEmacs was distributed with a PROBLEMS file that may describe your crash, and with luck a workaround. Please check it first, but do report the crash anyway. Please report this bug by invoking M-x report-emacs-bug, or by selecting `Send Bug Report' from the Help menu. If necessary, send ordinary email to `crashes@xemacs.org'. *MAKE SURE* to include the XEmacs configuration from M-x describe-installation, or equivalently the file Installation in the top of the build tree. *Please* try *hard* to obtain a C stack backtrace; without it, we are unlikely to be able to analyze the problem. Locate the core file produced as a result of this crash (often called `core' or `core.<process-id>', and located in the directory in which you started XEmacs or your home directory), and type gdb /var/tmp/portage/xemacs-21.4.17/work/xemacs-21.4.17/src/xemacs core then type `where' at the debugger prompt. No GDB on your system? You may have DBX, or XDB, or SDB. (Ask your system administrator if you need help.) If no core file was produced, enable them (often with `ulimit -c unlimited' in case of future recurrance of the crash. Lisp backtrace follows: Segmentation fault gdb says: Program received signal SIGSEGV, Segmentation fault. 0x2000000000f17220 in ?? () (gdb) bt #0 0x2000000000f17220 in ?? () #1 0x4000000000094200 in Fdevice_console () #2 0x0000000000000000 in ?? ()
Henrik, did you need to apply the patch in comment #2, or did xemacs 21.4.17 compile correctly out of the box? Also, you might want to try xemacs-21.4.20 because it fixes several crash bugs with byte-compiled code, and that is what seems to happen here.
No patches were needed to get 21.4.17 to compile.
xemacs-21.5.20 also builds fine (without any patches), and the resulting binary behaves the same as 21.5.17: $ xemacs -nw Fatal error (11). Your files have been auto-saved. Use `M-x recover-session' to recover them. Your version of XEmacs was distributed with a PROBLEMS file that may describe your crash, and with luck a workaround. Please check it first, but do report the crash anyway. Please report this bug by invoking M-x report-emacs-bug, or by selecting `Send Bug Report' from the Help menu. If necessary, send ordinary email to `xemacs-beta@xemacs.org'. *MAKE SURE* to include the XEmacs configuration from M-x describe-installation, or equivalently the file Installation in the top of the build tree. *Please* try *hard* to obtain a C stack backtrace; without it, we are unlikely to be able to analyze the problem. Locate the core file produced as a result of this crash (often called `core' or `core.<process-id>', and located in the directory in which you started XEmacs or your home directory), and type gdb /var/tmp/portage/xemacs-21.4.20/work/xemacs-21.4.20/src/xemacs core then type `where' at the debugger prompt. No GDB on your system? You may have DBX, or XDB, or SDB. (Ask your system administrator if you need help.) If no core file was produced, enable them (often with `ulimit -c unlimited' in case of future recurrance of the crash. Lisp backtrace follows: Segmentation fault gdb says: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 2305843009230512320 (LWP 5499)] 0x20000000010f4d90 in ?? () (gdb) bt #0 0x20000000010f4d90 in ?? () #1 0x4000000000094bc0 in Fdevice_console () #2 0x0000000000000000 in ?? ()
Unfortunately the stack trace in comment 6 is not really useful, probably due to lack of debugging info and optimizations. With this backtrace it really is not possible to solve this issue. A way to get a better backtrace is to compile xemacs with CFLAGS="-g -O0", that will likely give more details about what is going on.
Two more points related to this bug: I noticed that xemacs is not even keyworded ~ia64 at the moment, perhaps for good reason. I also noticed comments on the xemacs-beta mailing list that ia64 has a number of (unnamed) issues at the moment. One thing that was discussed was that on ia64 the system malloc should be used. If you would like to give this a try you will need to edit the ebuild. Right were it references bug #21264 you'd need to add the following line similar to those for ppc64 and alpha: use ia64 && myconf="${myconf} --with-system-malloc"
The following Redhat bug report may also be relevant: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=106744 The following inline patch is proposed on the xemacs-beta mailing list. It is for 21.5 but something like this could probably be done for 21.4 as well: --- xemacs-21.5.26/aclocal.m4.orig 2006-03-28 18:55:49.000000000 +0300 +++ xemacs-21.5.26/aclocal.m4 2006-04-04 21:11:33.000000000 +0300 @@ -549,11 +549,12 @@ dnl usually need to be prefix with ${wl} or some other such thing. dnl -if test "$xe_gnu_ld" = yes; then - if test "$ld_shlibs" = yes; then - ld_dynamic_link_flags="${wl}-export-dynamic" - fi -fi +dnl dnl avoid -export-dynamic on ia64 +dnl if test "$xe_gnu_ld" = yes; then +dnl if test "$ld_shlibs" = yes; then +dnl ld_dynamic_link_flags="${wl}-export-dynamic" +dnl fi +dnl fi if test -z "$ld_dynamic_link_flags"; then case "$xehost_os" in
The use of the system memory allocator for ia64 has been added to xemacs 21.4.20-r1. I'm closing this bug as TEST-REQUEST as I can't do much more on this without additional feedback. Feel free to re-open it when there is additional information.
