From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: emacs build failure on today's debian Date: Wed, 15 Jun 2011 18:38:11 +0900 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1308130724 8059 80.91.229.12 (15 Jun 2011 09:38:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 15 Jun 2011 09:38:44 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 15 11:38:40 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QWmYa-000714-LE for ged-emacs-devel@m.gmane.org; Wed, 15 Jun 2011 11:38:40 +0200 Original-Received: from localhost ([::1]:53259 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWmYZ-0000iA-Ms for ged-emacs-devel@m.gmane.org; Wed, 15 Jun 2011 05:38:39 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:50988) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWmYD-0000hX-0z for emacs-devel@gnu.org; Wed, 15 Jun 2011 05:38:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QWmYB-0008BK-4G for emacs-devel@gnu.org; Wed, 15 Jun 2011 05:38:16 -0400 Original-Received: from relmlor3.renesas.com ([210.160.252.173]:49048) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWmYA-0008As-Ia; Wed, 15 Jun 2011 05:38:14 -0400 Original-Received: from relmlir1.idc.renesas.com ([10.200.68.151]) by relmlor3.idc.renesas.com ( SJSMS) with ESMTP id <0LMT00LDWS3OIS50@relmlor3.idc.renesas.com>; Wed, 15 Jun 2011 18:38:12 +0900 (JST) Original-Received: from relmlac3.idc.renesas.com ([10.200.69.23]) by relmlir1.idc.renesas.com (SJSMS) with ESMTP id <0LMT000FHS3O8L90@relmlir1.idc.renesas.com>; Wed, 15 Jun 2011 18:38:12 +0900 (JST) Original-Received: by relmlac3.idc.renesas.com (Postfix, from userid 0) id 212C518071; Wed, 15 Jun 2011 18:38:12 +0900 (JST) Original-Received: from relmlac3.idc.renesas.com (localhost [127.0.0.1]) by relmlac3.idc.renesas.com (Postfix) with ESMTP id 1EE121807C; Wed, 15 Jun 2011 18:38:12 +0900 (JST) Original-Received: from relmlii1.idc.renesas.com [10.200.68.65] by relmlac3.idc.renesas.com with ESMTP id UAC26835; Wed, 15 Jun 2011 18:38:12 +0900 X-IronPort-AV: E=Sophos;i="4.65,369,1304262000"; d="scan'208";a="32137653" Original-Received: from unknown (HELO relay21.aps.necel.com) ([10.29.19.50]) by relmlii1.idc.renesas.com with ESMTP; Wed, 15 Jun 2011 18:38:12 +0900 Original-Received: from relay21.aps.necel.com ([10.29.19.50] [10.29.19.50]) by relay21.aps.necel.com with ESMTP; Wed, 15 Jun 2011 18:38:12 +0900 Original-Received: from dhlpc061 ([10.114.96.212] [10.114.96.212]) by relay21.aps.necel.com with ESMTP; Wed, 15 Jun 2011 18:38:11 +0900 Original-Received: by dhlpc061 (Postfix, from userid 31295) id D277C52E1F6; Wed, 15 Jun 2011 18:38:11 +0900 (JST) System-Type: x86_64-unknown-linux-gnu Blat: Foop In-reply-to: Original-Lines: 22 X-detected-operating-system: by eggs.gnu.org: Solaris 10 (1203?) X-Received-From: 210.160.252.173 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:140482 Archived-At: Julien Danjou writes: >> It seems pretty dodgy that Emacs is directly looking for these files at >> all, but oh well, I guess it's some messiness related to dumping. If it >> needs to use them, though, isn't there a less brittle way to find out >> where they are? > > You can fix it with passing this to configure: > > --with-crt-dir=/usr/lib/$(shell dpkg-architecture -qDEB_HOST_MULTIARCH)/ Right, that will work as a workaround right now, but I don't think users should _have_ to do that, if it's possible for configure to figure it out automatically. So my question is really about the right way to do it for the future. Thanks, -Miles -- My books focus on timeless truths. -- Donald Knuth