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.

Ok

>> 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 ;)

-- 
Niels




More information about the discussion mailing list


interactive