From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Some OpenWrt port related problems Date: Tue, 28 Dec 2010 17:02:29 -0500 Message-ID: References: <87sjxi5hko.fsf@snail.Pool> <87lj39y52n.fsf@snail.Pool> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1293575030 23497 80.91.229.12 (28 Dec 2010 22:23:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 28 Dec 2010 22:23:50 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kuehling Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 28 23:23:46 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PXhxJ-0000XN-DR for ged-emacs-devel@m.gmane.org; Tue, 28 Dec 2010 23:23:45 +0100 Original-Received: from localhost ([127.0.0.1]:46240 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PXhcq-0007jc-K9 for ged-emacs-devel@m.gmane.org; Tue, 28 Dec 2010 17:02:36 -0500 Original-Received: from [140.186.70.92] (port=42464 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PXhcm-0007iz-En for emacs-devel@gnu.org; Tue, 28 Dec 2010 17:02:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PXhcl-0001R5-9j for emacs-devel@gnu.org; Tue, 28 Dec 2010 17:02:32 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:61437 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PXhcl-0001R0-5q for emacs-devel@gnu.org; Tue, 28 Dec 2010 17:02:31 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANvtGU1FpZcL/2dsb2JhbACkMXS/CIVKBIRljhs X-IronPort-AV: E=Sophos;i="4.60,241,1291611600"; d="scan'208";a="86635766" Original-Received: from 69-165-151-11.dsl.teksavvy.com (HELO pastel.home) ([69.165.151.11]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 28 Dec 2010 17:02:30 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id AC07E58AC9; Tue, 28 Dec 2010 17:02:29 -0500 (EST) In-Reply-To: <87lj39y52n.fsf@snail.Pool> (David Kuehling's message of "Tue, 28 Dec 2010 22:12:48 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:134020 Archived-At: > Well unfortunate is that Emacs' Makefiles make a number of assumptions > that are completely incompatible with cross-compilation :) Like > compiling and executing the resulting program in a single Makefile rule. > The dumping is even more hackier. Didn't even know that such a > procedure is possible on current operating systems :) Yes, it's clearly not friendly to cross-compilation. There's a lot of room for improvement there, but given the reliance on dumping, there is very little motivation to actually make it cross-compilation friendly. > The problem with a simulated environment, that you're suggesting, is, > that OpenWrt packages (or rather the recipies used to compile a package) > need to be self-contained inside OpenWrt. If I needed a target system I'm somewhat familiar with OpenWRT, so I have an idea of how much work this would require in general. But some targets may come with "readily available" simulators, so I thought maybe that was the case for the NanoNote as well. >>> Now I'm hitting another problem when using org-mode: File mode >>> specification error: (wrong-type-argument stringp (require >>> . t-mouse)) After some debugging this looks like being caused by >>> variable load-history containing the element: ((require . t-mouse)) >>> This looks a little broken, since all other elements have a >>> filename-string in front of that cons cell, e.g.: >> That one doesn't remind me of anything. > Hmm, so maybe related to the CANNOT_DUMP config (note: it's not NO_DUMP, > my mistake). Yes, very likely. >> That's the question, yes. But no, I have no idea how this can happen. > Ok, thanks for the answers. Then it might be time to do some more > in-depth debugging to see where in loadup.el that entry originates. Indeed. Grepping for Vload_file_name, Vload_history, and CANNOT_DUMP might give you a good start. Good luck, Stefan