Because emac's dumping procedure assumes glibc internals on linux. It segfaults on musl libc based systems. Attached are patches for the musl branch of the hardened-development overlay. The first patch adds emacs-24.4 for which an ugly LD_PRELOAD hack from Rich Felker is applied. The second patch adds emacs-vcs-25.0.9999 with a relatively clean patch. (but still not suited for upstreaming.) Reproducible: Always
Created attachment 395624 [details, diff] emacs-24.4
Created attachment 395626 [details, diff] emacs-vcs-25.0.9999
Please describe the problem in detail.
(In reply to Felix Janda from comment #0) > Because emac's dumping procedure assumes glibc internals on linux. It > segfaults on musl libc based systems. > > Attached are patches for the musl branch of the hardened-development overlay. > > The first patch adds emacs-24.4 for which an ugly LD_PRELOAD hack from Rich > Felker is applied. Which does the following in its src_compile(): + $(tc-getCC) -shared -fPIC -o preload.so "${FILESDIR}/preload.c" || die WONTFIX for this. > The second patch adds emacs-vcs-25.0.9999 with a relatively clean patch. > (but still not suited for upstreaming.) As a matter of principle, we don't patch the live version, because it is a moving target and the patch may fail at any point of time. So if you want this, submit it upstream please.
The patches are NOT intended for the portage tree. They are for blueness' musl branch of the hardened-development overlay. It collects often hacky patches to make things work with musl libc. In particular the patches I've sent would break all other platforms. The problem is discussed on the emacs mailing list: http://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00223.html emacs used glibc malloc internals to make its "dumping" process work on linux. musl doesn't have the assumptions made on the malloc implementation resulting in segfaults when trying to dump. The LD_PRELOAD hack for emacs-24 overrides the malloc used before dumping. After dumping the usual malloc is used. The patch for emacs git master makes it use the new (August 2014) hybrid malloc, i.e. use an emacs provided malloc before dumping, use libc malloc after dumping. Hopefully the patch becomes soon obsolete. Refer also to the discussion on the musl list: http://www.openwall.com/lists/musl/2015/02/03/1
I see. Reassigning (and reopening) then.
(In reply to Ulrich Müller from comment #6) > I see. Reassigning (and reopening) then. Thanks ulm. I've asked people to assign bugs like this to me and just cc maintainers fyi, but there's no way for reporters to assign bugs. Some patch on the musl overlay are hacky, others could/should/will go upstream. The overlay is the clearinghouse were we work out those details. @jer any recommendation how to get bugs like this assigned to me?
