From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Hin-Tak Leung Newsgroups: gmane.emacs.bugs,gmane.emacs.help Subject: SOLVED: Emacs (all versions) dumps core when built against XFree86 4.3 Date: Tue, 13 May 2003 05:10:10 +0100 Sender: bug-gnu-emacs-bounces+gnu-bug-gnu-emacs=m.gmane.org@gnu.org Message-ID: <3EC07022.8060309@yahoo.co.uk> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1052798770 25125 80.91.224.249 (13 May 2003 04:06:10 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 13 May 2003 04:06:10 +0000 (UTC) Cc: rms@gnu.org Original-X-From: bug-gnu-emacs-bounces+gnu-bug-gnu-emacs=m.gmane.org@gnu.org Tue May 13 06:06:05 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19FR3F-0006Wq-00 for ; Tue, 13 May 2003 06:06:05 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19FR3k-0006oX-00 for gnu-bug-gnu-emacs@m.gmane.org; Tue, 13 May 2003 00:06:36 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 19FR3F-0006PM-00 for bug-gnu-emacs@gnu.org; Tue, 13 May 2003 00:06:05 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 19FR3C-0006Ld-00 for bug-gnu-emacs@gnu.org; Tue, 13 May 2003 00:06:03 -0400 Original-Received: from smtp012.mail.yahoo.com ([216.136.173.32]) by monty-python.gnu.org with smtp (Exim 4.10.13) id 19FR1h-0005lf-00 for bug-gnu-emacs@gnu.org; Tue, 13 May 2003 00:04:29 -0400 Original-Received: from m5-mp1.cvx1-c.cam.dial.ntli.net (HELO yahoo.co.uk) (hintak?leung@62.253.152.5 with plain) by smtp.mail.vip.sc5.yahoo.com with SMTP; 13 May 2003 04:04:27 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en, en-us Original-To: mikeirw@pobox.com, bug-gnu-emacs@gnu.org, help-gnu-emacs@gnu.org Original-cc: samuel@ma.hw.ac.uk Original-cc: ttn@glug.org X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Bug reports for GNU Emacs, the Swiss army knife of text editors List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: bug-gnu-emacs-bounces+gnu-bug-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.bugs:5038 gmane.emacs.help:9647 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:5038 Apparently the problem is applicable to all version of emacs (including latest CVS, back to 19.34b), on all unix/unix-like systems for which GNU ld is the default linker, and for which GNU ld is quite up-to-date. Symptom: emacs dump cores at XtInitializeWidgetClass () with 'Fatal Error (11).Segmentational Fault' Solution: Adding '-z nocombreloc' to LDFLAGS Reason: 'combreloc' has become the default for recent GNU ld, which breaks the unexec/undump of both emacs and xemacs (all versions). This information should be useful to a *lot* of people. =========== Many after-thoughts: (1) The problem has been very recently reported against CVS version of GNU emacs in March 2003 (i.e. two months ago), and even caught Mr Stallman's attention briefly, no solution is known to the GNU Emacs people; and yet the xemacs people apparently had the fix integrated to their ./configure for almost a year now... (2) The GNU emacs people/community has not been at all helpful... I guessed the origin of the problem myself, made my own suggestion to do a gdb back trace, did my own search for any problem associated with 'XtInitializeWidgetClass'... the same problem was reported by others to the xemacs mailing lists, and the correct solution was suggested by more than a few patient individuals, according to their archive... (3) Sadly, judging from the reaction to the same problem in both archives, I have to say the xemacs community probably are more "free" (in the beer sense) than the GNU emacs community... xemacs people gave sound technical advices and solutions, GNU emacs people gave lectures on "employer/employee relationships"... (For software projects for which I participate deeply, I don't have any problem with "ordering" people to give or obtain more details... this has nothing to do with employer/employee relationship - supplying more details just help the diagnostic process, and ultimately benefit the individual himself who supplies the details)