From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kuehling Newsgroups: gmane.emacs.devel Subject: Re: Some OpenWrt port related problems Date: Tue, 28 Dec 2010 22:12:48 +0100 Message-ID: <87lj39y52n.fsf@snail.Pool> References: <87sjxi5hko.fsf@snail.Pool> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Trace: dough.gmane.org 1293570793 5686 80.91.229.12 (28 Dec 2010 21:13:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 28 Dec 2010 21:13:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 28 22:13:09 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 1PXgqy-0004sF-LW for ged-emacs-devel@m.gmane.org; Tue, 28 Dec 2010 22:13:08 +0100 Original-Received: from localhost ([127.0.0.1]:40588 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PXgqx-0007Hi-Ul for ged-emacs-devel@m.gmane.org; Tue, 28 Dec 2010 16:13:07 -0500 Original-Received: from [140.186.70.92] (port=46438 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PXgqp-0007HY-Em for emacs-devel@gnu.org; Tue, 28 Dec 2010 16:13:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PXgqh-0001uu-QR for emacs-devel@gnu.org; Tue, 28 Dec 2010 16:12:59 -0500 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:33598 helo=mail.gmx.net) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1PXgqh-0001ug-Fl for emacs-devel@gnu.org; Tue, 28 Dec 2010 16:12:51 -0500 Original-Received: (qmail invoked by alias); 28 Dec 2010 21:12:50 -0000 Original-Received: from g225039250.adsl.alicedsl.de (EHLO snail.gmx.de) [92.225.39.250] by mail.gmx.net (mp018) with SMTP; 28 Dec 2010 22:12:50 +0100 X-Authenticated: #4121607 X-Provags-ID: V01U2FsdGVkX1/8e9kdWe7875kefy86He9ENvUkuEJ2Dv5FL8uNyF neBn0XxnFZ/I4e In-Reply-To: (Stefan Monnier's message of "Tue, 28 Dec 2010 14:36:39 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-Y-GMX-Trusted: 0 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:134017 Archived-At: --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Stefan" =3D=3D Stefan Monnier writes: >> OpenWrt packages use cross-compilation, so Emacs is used in a NO_DUMP >> configuration, loading loadup.el every time it starts. > That's unfortunate, as this is completely untested and unsupported. I > expect you'll bump into further problems. Maybe a "simpler" solution > is to setup a simulation environment where you could perform the dump. 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 :) 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 emulator I'd have to write a recipie how to compile one on any host and add a build-dependency to it. Quite some work, and maybe not even possible in a completely stable way. Qemu user-space emulation for the MIPS32 target seems currently broken (at least it doesn't work for me), so I'd even need to write a rule for how to generate a root-filesystem to get into a simulated environment. And that would have to work for every of the target CPUs that OpenWrt supports :/ >> This causes at least one problem with environment variables, that I >> already fixed [3]. > Not sure if that's the right fix, but indeed there's a bug there that > shows up when using NO_DUMP. Make sure you record it via M-x > report-emacs-bug. Going to do that eventually. >> 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). >> Anybody knows who's fault that error is anyways? > I don't. >> is ((require . t-mouse)) a valid entry? > No. >> Is eval-after-load broken? > Not that I know. >> How does that entry get inserted into load-history in the first >> place? > 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. cheers, David =2D-=20 GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFNGlLRfe9TI8F0fUARArgXAJ0bbhycRUIY41pHFK5L2Di8MZ0TugCdGoXR UfMJpfQSZAOMsU7RZIHLmqI= =ztKX -----END PGP SIGNATURE----- --=-=-=--