On Feb 2, 2015 10:54 PM, "Rich Felker" <dalias@libc.org> wrote:
>
> Background: GNU Emacs' build process depends on the ability of the
> build-stage binary (temacs) to "dump" itself to a new executable file
> containing preloaded lisp objects/state in its .data segment. This
> process is highly non-portable even in principle; in practice, the big
> issue is where malloc allocations end up. They need to all be
> contiguous just above the .data/.bss in the original binary so that
> they can become part of the .data mapping. Against musl's malloc, this
> has two major ways it can fail:
>
> 1. musl uses mmap for large allocations (roughly, > 128-256k) and has
>    no mechanism for obtaining such large objects from the main
>    brk-based heap or even requesting such (whereas glibc has mallopt
>    and/or an environment variable to control the mmap threshold, and
>    emacs cheats and uses that to control glibc).
>
> 2. musl reclaims the gaps around the edges of writable mappings in the
>    main program and shared libraries and uses them for malloc. If
>    these are in shared libraries, they won't be dumped at all, and if
>    they're in the main program, they actually overlap with .text on
>    disk (the same page is mapped twice; this is the cause of the gaps)
>    and thus the .text, not the heap data, gets written out to disk by
>    the dumper.
>
> Emacs provides its own malloc replacement and tries to use it by
> default, but this has to be disabled with musl, since replacing malloc
> in dynamic programs doesn't work (and static binaries don't work right
> at all with emacs' dumper because libc state would get included in the
> dump -- state which is "intentionally lost" when it resides in a
> shared library whose state isn't dumped).
>
> The right solution: As I discussed on the emacs-devel list nearly a
> year ago, the right solution is to get rid of the non-portable code in
> emacs, dumping the lisp heap and its data (rather than the whole
> program) to a file and either mmapping it at runtime (and possibly
> relocating pointers in it, if the new location it's loaded at differs)
> or converting it to a C source file that's compiled and linked and for
> which the (static or dynamic) linker can perform relocations at
> link/load time. This solution also solves a number of other serious
> issues related to the dumper, including its incompatibility with PIE
> binaries.
>
> Unfortunately, the right solution requires a significant overhaul by
> someone with expertise in emacs internals, and it's not practical in
> the short term. Meanwhile, we have users wanting emacs on musl-based
> distros (myself included).
>
> So, here's an alternate solution.

I think there was a guy on the toybox list working on editors and might
have a emacs for you. Onefang comes to mind.