Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 73366 - xemacs-21.4.15-r2 fails to build on 2.6.8-gentoo-r3/ia64
Summary: xemacs-21.4.15-r2 fails to build on 2.6.8-gentoo-r3/ia64
Status: RESOLVED TEST-REQUEST
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: IA64 Linux
: High normal (vote)
Assignee: XEmacs team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-12-04 11:51 UTC by Henrik Grubbström
Modified: 2007-01-07 13:03 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Henrik Grubbström 2004-12-04 11:51:20 UTC
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"
Comment 1 Hans de Graaff gentoo-dev 2006-12-10 01:31:21 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.
Comment 2 Hans de Graaff gentoo-dev 2006-12-11 23:27:15 UTC
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
Comment 3 Henrik Grubbström 2006-12-13 02:47:17 UTC
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 ?? ()
Comment 4 Hans de Graaff gentoo-dev 2006-12-17 02:33:55 UTC
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.
Comment 5 Henrik Grubbström 2006-12-18 01:54:58 UTC
No patches were needed to get 21.4.17 to compile.
Comment 6 Henrik Grubbström 2006-12-18 02:44:56 UTC
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 ?? ()
Comment 7 Hans de Graaff gentoo-dev 2006-12-19 12:55:33 UTC
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.
Comment 8 Hans de Graaff gentoo-dev 2006-12-26 23:43:53 UTC
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"
Comment 9 Hans de Graaff gentoo-dev 2006-12-28 00:35:22 UTC
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
Comment 10 Hans de Graaff gentoo-dev 2007-01-07 13:03:29 UTC
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.