From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Newsgroups: gmane.emacs.help Subject: Installation problem of Emacs 21.3 with GCC 3.3 /Sparc Solaris 8. Date: Tue, 1 Jul 2003 07:29:08 +0900 (JST) Sender: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1057016930 30670 80.91.224.249 (30 Jun 2003 23:48:50 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 30 Jun 2003 23:48:50 +0000 (UTC) Cc: ishikawa@yk.rim.or.jp Original-X-From: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Tue Jul 01 01:48:45 2003 Return-path: Original-Received: from hermes.netfonds.no ([80.91.224.195]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19X8O4-0007yH-00 for ; Tue, 01 Jul 2003 01:48:45 +0200 Original-Received: from monty-python.gnu.org (monty-python.gnu.org [199.232.76.173]) by hermes.netfonds.no (8.12.8p1/8.12.8) with ESMTP id h5UNnB80001485 for ; Tue, 1 Jul 2003 01:49:12 +0200 (CEST) Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19X86y-0006Ju-9O for gnu-help-gnu-emacs@m.gmane.org; Mon, 30 Jun 2003 19:31:04 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19X7gm-0002Vk-GY for help-gnu-emacs@gnu.org; Mon, 30 Jun 2003 19:04:00 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19X7VI-0007sH-Sd for help-gnu-emacs@gnu.org; Mon, 30 Jun 2003 18:52:17 -0400 Original-Received: from pl227.nas911.n-yokohama.nttpc.ne.jp ([210.139.98.227] helo=standard.erephon) by monty-python.gnu.org with esmtp (Exim 4.20) id 19X787-0002wg-TN for help-gnu-emacs@gnu.org; Mon, 30 Jun 2003 18:28:12 -0400 Original-Received: by yk.rim.or.jp via sendmail from stdin id (Debian Smail3.2.0.114) for help-gnu-emacs@gnu.org; Tue, 1 Jul 2003 07:29:08 +0900 (JST) Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:11356 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:11356 I have an installation problem of Emacs 21.3 using GCC 3.3 under UltraSparc Solaris 8. I suspect a bug of GCC 3.3 (and opened a bug report at bugzilla of gcc.gnu.org, bug 11386), but wonder if others have experienced similar problems using the recent GCC versions. However, GCC 3.2.3 works fine and I could install Emacs using 3.2.3. But I have other reasons to prefer using GCC 3.3 on the said machine, and so would like to resolve the issue one way or the other if possible. Below is a quote from somewhat edited bug report that I posted to bugzilla at gcc.gnu.org. Since emacs is a huge program, even if it is GCC 3.3 that miscompiles the code, it is hard to isolate the problem into a small section of C source code in Emacs. I would appreciate to hear similar experiences under various platforms (this would help GCC folks to dig deeper into the problem or narrow the search area) and workaround. And if someone knows the exact cause (a bug in GCC 3.3 maybe?), that would be great. (Is it possible that unexec.c or its friend need modification for GCC 3.3, or configure is not picking up the proper unexec*.c for GCC 3.3 and solaris 8 combination? Wild guess at best.) Happay Hacking Ishikawa, Chiaki --- begin quote --- This is still insufficient information, but I am posting the gdb log to solicit more input from Emacs user community who may have experienced similar problems using the latest GCC 3.3 under sparc solaris and other platforms. Basically, after a binary compile of the emacs program, the emacs installer tries to compile so called emacs lisp programs into its own internal byte code. During the byte compiling, emacs aborts. The final gdb output is as follows: (details below.) |Program received signal SIGSEGV, Segmentation fault. |0x41e90 in __do_global_dtors_aux () |(gdb) #0 0x41e90 in __do_global_dtors_aux () |#1 0x18931c in _fini () |#2 0xfee9bca4 in _exithandle () from /usr/lib/libc.so.1 |#3 0xfef1f87c in exit () from /usr/lib/libc.so.1 |#4 0xd2b20 in Fkill_emacs (arg=0) at emacs.c:1830 |#5 0x137d20 in Ffuncall (nargs=1, args=0xffbee31c) at eval.c:2659 This suggests that a part of emacs gets miscompiled by by GCC 3.3 under ultra sparc solaris 8. Emacs seems to have detected something funny and tries to quit calling Fkill_emacs function, but by that time, something (memory[code/stack] area?) was either broken from the beginning or corrupted during the run, and during the exit processing the program seems to have encountered a fatal segmentation error. Using GCC 3.2.3 under the same OS, the byte compilation succeeds and the installation succeeds. The resulting Emacs is usable as far as I can tell. Atttached is the problematic run, under gdb, of the Emacs binary that gets compiled using gcc 3.3. I run a particular byte compilation that triggered the abort by using a shell script break.sh. It runs the EMACS binary under gdb. $ cat break.sh LC_ALL=C LANG=C gcc -v cd leim EMACSLOADPATH=/home/ishikawa/PACKAGES/emacs-21.3/leim/../lisp export EMACSLOADPATH # ../src/emacs -batch --no-init-file --no-site-file --multibyte -l /home/ishikawa/PACKAGES/emacs-21.3/leim/../lisp/international/titdic-cnv \ --eval '(batch-titdic-convert t)' -dir quail /home/ishikawa/PACKAGES/emacs-21.3/leim/CXTERM-DIC; ***** The above backslash was followed by CR (invisible) and ***** this caused the --eval not found error below, but ***** this has nothing to do with the compilation problem. gdb ../src/emacs < to continue, or q to quit--- at eval.c:2851 #8 0x138020 in apply_lambda (fun=1078908320, args=1, eval_flag=1) at eval.c:2770 #9 0x136c58 in Feval (form=1346736020) at eval.c:2071 #10 0x137d20 in Ffuncall (nargs=1, args=0xffbee66c) at eval.c:2659 #11 0x166714 in Fbyte_code (bytestr=-4266392, vector=2613852, maxdepth=11) at bytecode.c:716 #12 0x138170 in funcall_lambda (fun=1076354016, nargs=1, arg_vector=0xffbee834) at eval.c:2851 #13 0x137c0c in Ffuncall (nargs=1, args=0xffbee830) at eval.c:2716 #14 0x166714 in Fbyte_code (bytestr=-4265936, vector=2604088, maxdepth=5) at bytecode.c:716 #15 0x138170 in funcall_lambda (fun=1076344624, nargs=0, arg_vector=0xffbee9e4) at eval.c:2851 #16 0x137c0c in Ffuncall (nargs=0, args=0xffbee9e0) at eval.c:2716 #17 0x166714 in Fbyte_code (bytestr=-4265504, vector=2599040, maxdepth=5) at bytecode.c:716 #18 0x138170 in funcall_lambda (fun=1076340688, nargs=0, arg_vector=0xffbeeb00) at eval.c:2851 #19 0x138020 in apply_lambda (fun=1076340688, args=0, eval_flag=1) at eval.c:2770 #20 0x136c58 in Feval (form=1345428916) at eval.c:2071 #21 0x135a3c in internal_condition_case (bfun=0xd3da0 , ---Type to continue, or q to quit--- handlers=271329500, hfun=0xd3a5c ) at eval.c:1267 #22 0xd3df0 in top_level_1 () at keyboard.c:1262 #23 0x135598 in internal_catch (tag=271281828, func=0xd3db8 , arg=271207428) at eval.c:1030 #24 0xd3d04 in command_loop () at keyboard.c:1223 #25 0xd37a8 in recursive_edit_1 () at keyboard.c:950 #26 0xd390c in Frecursive_edit () at keyboard.c:1006 #27 0xd2690 in main (argc=0, argv=0xffbef104, envp=0xffbef138) at emacs.c:1547 (gdb) (gdb) (gdb) $ $ exit --- end quote --- [end of memo]