The Emacs dumper dispute

When the malloc_get/set_state() functions are not available, Emacs falls back to a built-in malloc(), which is slower and less efficient than glibc malloc(), but works (or was believed to until this ralloc() issue turns up). malloc_set_state() -- used when loading a previously-dumped Emacs -- *still exists* in newer glibc, but as a compat symbol that cannot be linked against: glibc will detect when the old heap format is used by something calling malloc_set_state() (i.e., by an Emacs linked against an older glibc) and will mark the old heap dynamically as something allocated but unfreeable, which is good enough to work with a newer glibc no matter what its malloc implementation (but unlike in older glibc, the dumped heap remains a separate arena which the new malloc() is ignorant of, so free()ing from it does nothing, and new malloc()s will never come out of that arena). However, newly-compiled Emacsen will obviously not get a heap format compatible with this scheme, so malloc_get_state() is not available even as a compat symbol (or, rather, it is, because Emacs still has an undefined symbol referring to it, but its implementation has been stubbed out and always returns -ENOSYS).

I'll have to catch up with the emacs dev list, clearly -- I had no idea about this latest ralloc mess, though it was probably predictable because next to nothing has used ralloc for years so it has probably bitrotted catastrophically.