>>>>> "Stefan" == 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 -- GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40