Re: Some OpenWrt port related problems

[Stefan Monnier <monnier@iro.umontreal.ca>]

> 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