problems compiling emacs natively on the nanonote
dvdkhlng at gmx.de
Sat Jun 18 08:29:27 EDT 2011
>>>>> "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.
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 :)
GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the discussion