problems compiling emacs natively on the nanonote
Niels Felsted Thorsen
nift at maclisp.org
Sat Jun 18 18:00:55 EDT 2011
David Kuehling <dvdkhlng at gmx.de> writes:
>>>>>> "Niels" == Niels Felsted Thorsen <nift at maclisp.org> writes:
>> Hi I'm very happy with emacs on the nanonote in the official
>> image. Using it with org-mode for notetaking. However it takes forever
>> to start up (~74 seconds measured here), and emacs on debian on the
>> nanonote starts up in a few seconds. As I understand it, it is because
>> emacs build under openwrt, there is problems running the "second
>> stage" in the build process.
> Yea, the second stage means: loading all lisp files, than dumping a copy
> of emacs' memory to disk (i.e. "hibernating" the emacs process) to use
> for short-circuiting later startups of emacs.
>> So I thought, why not build emacs natively on the nanonote?
> I already tried to perform the second stage once on the nanonote, when
> emacs is started for the first time. However, it does require more RAM
> than is currently available in our NanoNotes. Cannot do much about that
> (don't want to enable swap just for that).
>> I downloaded the 23.3 sources of emacs, untarred, and ran
>> Running temacs just fails with "Illegal instruction". So does anybody
>> have any idea why this could be the case?
> The dumping of emacs memory and later re-loading is a pretty hacky
> method. They even ship assembler files to to the initial emacs startup
> etc. Probably their hacks don't really work with uclibc.
Ok, hmm, then I probably won't invest more time into this.
> I heard that xemacs has a saner method of dumping (i.e. serializing its
> internal lisp structures, instead of just dumping memory).
> I think the best solution would be to implement hibernation support on
> our nanonotes, so you won't have to restart emacs over and over :)
That would be nice ;)
More information about the discussion