From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Pretest Date: Sun, 29 Oct 2006 02:43:57 -0500 Message-ID: References: <87lkn1tzav.fsf@stupidchicken.com> <87wt6ka3ij.fsf@stupidchicken.com> <87ejssjhh0.fsf@furball.mit.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1162107858 19490 80.91.229.2 (29 Oct 2006 07:44:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 29 Oct 2006 07:44:18 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 29 08:44:17 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Ge5L7-00058f-4e for ged-emacs-devel@m.gmane.org; Sun, 29 Oct 2006 08:44:17 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ge5L6-0000bF-DF for ged-emacs-devel@m.gmane.org; Sun, 29 Oct 2006 02:44:16 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ge5Ks-0000ZR-RD for emacs-devel@gnu.org; Sun, 29 Oct 2006 02:44:02 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ge5Ks-0000Z0-B9 for emacs-devel@gnu.org; Sun, 29 Oct 2006 02:44:02 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ge5Ks-0000YY-5g for emacs-devel@gnu.org; Sun, 29 Oct 2006 02:44:02 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Ge5Ks-0004hW-96 for emacs-devel@gnu.org; Sun, 29 Oct 2006 02:44:02 -0500 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.34) id 1Ge5Kn-00021f-7M; Sun, 29 Oct 2006 02:43:58 -0500 Original-To: Chong Yidong In-reply-to: <87ejssjhh0.fsf@furball.mit.edu> (message from Chong Yidong on Sat, 28 Oct 2006 16:47:07 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:61328 Archived-At: > From: Chong Yidong > Date: Sat, 28 Oct 2006 16:47:07 -0400 > Cc: emacs-devel@gnu.org > > I'm using the version shipped with Ubuntu Dapper, version 2.59a-7 This version sounds like it's some kind of development snapshot. Can you try to find out? Maybe we shouldn't be using this version. > We could revert configure to the last version used, and stick with > the configure script for the rest of the pretest. That's not a good solution, IMO, since some bugs reported during the pretest might require to regenerate the script. > > I'd still like to understand what failed `ld'. > > I think the easiest thing to do is to apply the hunks of the diff > until you find which part causes compilation to fail for you. It > shouldn't take that long with a binary-search. I don't know when I'll have time to do that; fencepost.gnu.org is not my main machine. Even if I do find the portion of the diffs that causes the problem, then what? We don't have a version of Autoconf that would have the effect of applying only part of the diffs, so once again we will be in a position where regenerating the configure script would be difficult of impossible. And on top of that, I still have trouble understanding how any change in the configure script _alone_ could have anything to do with this. Unless I'm missing something, there are only 2 ways Autoconf can affect the temacs build: either through config.in/config.h, or through src/Makefile. These are the only two things I know off that affect compilation and linking of the C sources. However, in this case, config.in and config.h are identical to the ones you included in the tarball, and so is src/Makefile.in. Am I missing something? So I'm still thinking the `ld' failure was some real problem, and the changes in the configure script are only indirectly related to it. If someone knows how to investigate the `ld' failure (short of rebuilding Binutils with debug info and running `ld' under a debugger), I'd appreciate any ideas.