Summary: | xemacs-21.4.15-r2 fails to build on 2.6.8-gentoo-r3/ia64 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Henrik Grubbström <grubba> |
Component: | New packages | Assignee: | XEmacs team <xemacs> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | IA64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Henrik Grubbström
2004-12-04 11:51:20 UTC
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. |