emacs-24.4 fails to build on Gentoo Hardened/AMD64 with the following build error: if test "no" = "yes"; then \ rm -f bootstrap-emacs; \ ln temacs bootstrap-emacs; \ else \ ./temacs --batch --load loadup bootstrap || exit 1; \ test "X/sbin/paxctl" = X || /sbin/paxctl -zex emacs; \ mv -f emacs bootstrap-emacs; \ fi /bin/sh: line 7: 1591 Killed ./temacs --batch --load loadup bootstrap Makefile:815: recipe for target 'bootstrap-emacs' failed make[1]: *** [bootstrap-emacs] Error 1 make[1]: Leaving directory '/var/tmp/portage/app-editors/emacs-24.4/work/emacs-24.4/src' Makefile:382: recipe for target 'src' failed make: *** [src] Error 2 I'm not seeing anything relevant in the logs as to why `temacs` is being killed. Reproducible: Always Steps to Reproduce: 1. Install Gentoo Hardened on an AMD64. 2. env ACCEPT_KEYWORDS="~amd64" emerge '=app-editors/emacs-24.4' 3. Fail. Actual Results: The build fails because `temacs` is "killed". Expected Results: The build should have completed successfully.
Created attachment 387462 [details] emerge --info '=app-editors/emacs-24.4::gentoo'
Created attachment 387464 [details] emerge -pqv '=app-editors/emacs-24.4::gentoo'
Created attachment 387466 [details] build.log
Created attachment 387468 [details] environment
dmesg output should tell you why it was killed.
What are the values of XATTR_PAX_FLAGS and PT_PAX_FLAGS in your kernel's configuration?
(In reply to Ulrich Müller from comment #6) > What are the values of XATTR_PAX_FLAGS and PT_PAX_FLAGS in your kernel's > configuration? # gzip -cd /proc/config.gz| grep PAX_FLAGS CONFIG_PAX_PT_PAX_FLAGS=y CONFIG_PAX_XATTR_PAX_FLAGS=y
Created attachment 387494 [details, diff] 01_all_pax-xattr.patch Looks like this is the issue from bug 497498 again. I'll check with the hardened team if we need a longer transition period. Meanwhile, can you test if attached patch fixes the problem for you?
(In reply to Ulrich Müller from comment #8) > Meanwhile, can you test if attached patch fixes the problem for you? Yes and no. `temacs` is no longer killed and starts running but segfaults after loading some files. if test "no" = "yes"; then \ rm -f bootstrap-emacs; \ ln temacs bootstrap-emacs; \ else \ ./temacs --batch --load loadup bootstrap || exit 1; \ test "X/sbin/paxctl" = X || /sbin/paxctl -zex emacs; \ mv -f emacs bootstrap-emacs; \ fi Loading loadup.el (source)... Using load-path (/var/tmp/portage/app-editors/emacs-24.4/work/emacs-24.4/lisp /var/tmp/portage/app-editors/emacs-24.4/work/emacs-24.4/lisp/emacs-lisp /var/tmp/portage/app-editors/emacs-24.4/work/emacs-24.4/lisp/language /var/tmp/portage/app-editors/emacs-24.4/work/emacs-24.4/lisp/international /var/tmp/portage/app-editors/emacs-24.4/work/emacs-24.4/lisp/textmodes /var/tmp/portage/app-editors/emacs-24.4/work/emacs-24.4/lisp/vc) Loading emacs-lisp/byte-run... Loading emacs-lisp/backquote... Loading subr... [..] Loading electric... Loading tooltip... Loading /var/tmp/portage/app-editors/emacs-24.4/work/emacs-24.4/lisp/leim/leim-list.el (source)... Finding pointers to doc strings... Finding pointers to doc strings...done Dumping under the name emacs /bin/sh: line 7: 25667 Segmentation fault ./temacs --batch --load loadup bootstrap Makefile:815: recipe for target 'bootstrap-emacs' failed make[1]: *** [bootstrap-emacs] Error 1 make[1]: Leaving directory '/var/tmp/portage/app-editors/emacs-24.4/work/emacs-24.4/src' Makefile:382: recipe for target 'src' failed make: *** [src] Error 2 Backtrace: # paxctl-ng -psmer temacs # gdb --args ./temacs --batch --load loadup bootstrap [..] Program received signal SIGSEGV, Segmentation fault. 0x000003fff5d95870 in ?? () from /lib64/libc.so.6 (gdb) bt #0 0x000003fff5d95870 in ?? () from /lib64/libc.so.6 #1 0x000002aaaac30abb in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) at /usr/include/bits/string3.h:51 #2 unexec (new_name=0x2aaaba9f1b0 "/var/tmp/portage/app-editors/emacs-24.4/work/emacs-24.4/src/emacs", old_name=0x2aaaba9f200 "/var/tmp/portage/app-editors/emacs-24.4/work/emacs-24.4/src/temacs") at unexelf.c:1060 #3 0x000002aaaab657ea in Fdump_emacs (filename=2932047330049, symfile=2932047329617) at emacs.c:2153 #4 0x000002aaaabf399c in eval_sub (form=<optimized out>) at eval.c:2185 #5 0x000002aaaabf3ebd in Fprogn (body=2932039658006) at eval.c:462 #6 0x000002aaaabf3b2c in eval_sub (form=<optimized out>) at eval.c:2132 #7 0x000002aaaabf3b2c in eval_sub (form=form@entry=2932038684374) at eval.c:2132 #8 0x000002aaaac1d5bf in readevalloop (readcharfun=2932038827458, stream=stream@entry=0x2aaab244b50, sourcename=sourcename@entry=2932038977329, printflag=printflag@entry=false, unibyte=<optimized out>, readfun=2932038709106, start=2932038709106, end=2932038709106) at lread.c:1934 #9 0x000002aaaac1e00b in Fload (file=2932038977073, noerror=<optimized out>, nomessage=2932038709106, nosuffix=<optimized out>, must_suffix=<optimized out>) at lread.c:1363 #10 0x000002aaaabf3915 in eval_sub (form=form@entry=2932038972742) at eval.c:2196 #11 0x000002aaaabf81e3 in Feval (form=2932038972742, lexical=<optimized out>) at eval.c:1997 #12 0x000002aaaabf233c in internal_condition_case (bfun=bfun@entry=0x2aaaab6d940 <top_level_2>, handlers=<optimized out>, hfun=hfun@entry=0x2aaaab732b0 <cmd_error>) at eval.c:1348 #13 0x000002aaaab6d92d in top_level_1 (ignore=ignore@entry=2932038709106) at keyboard.c:1194 #14 0x000002aaaabf220a in internal_catch (tag=2932038756242, func=func@entry=0x2aaaab6d890 <top_level_1>, arg=2932038709106) at eval.c:1112 #15 0x000002aaaab72c74 in command_loop () at keyboard.c:1155 #16 recursive_edit_1 () at keyboard.c:777 #17 0x000002aaaab73165 in Frecursive_edit () at keyboard.c:848 #18 0x000002aaaaac5aa4 in main (argc=<optimized out>, argv=<optimized out>) at emacs.c:1646
Do you see the problem with emacs-24.3-r6 too?
(In reply to Ulrich Müller from comment #10) > Do you see the problem with emacs-24.3-r6 too? No, I just (re)merged it and it worked fine.
It's not clear to me what would cause this, and I don't have a hardened system at hand where I could test it myself. If you want to help investigating this (which would be much appreciated), here are some ideas: - Replace src/unexelf.c with the file from emacs-24.3, then try to compile. - Other way around, compile 24.3 with src/unexelf.c from 24.4. - Compile emacs-24.4 with -DUNEXELF_DEBUG in CFLAGS, to see what is going on.
(In reply to David Holm from comment #9) I think you can skip the steps in Comment 12 as I do have a hardened system and have reproduced a similar problem. Instead, in addition to applying the pax xattr patch as you did earlier, please try adding this line in src_configure after strip-flags: use pax_kernel && append-flags -nopie If that doesn't work, then instead of the patch you could try this sed at the end of src_prepare (as well as the above line in src_configure): sed -e 's@\$(PAXCTL) -r temacs\$(EXEEXT)@\$(PAXCTL) -er temacs\$(EXEEXT)@' \ -e 's@$(SETFATTR) -n user.pax.flags -v r@$(SETFATTR) -n user.pax.flags -v er@' \ -i "${S}/src/Makefile.in" \ || die "unable to sed src/Makefile.in" the only difference is the sed is also changing the paxctl to use -er instead of -r .
(In reply to Mark Wright from comment #13) > Instead, in addition to applying the pax xattr patch as you did earlier, > please try adding this line in src_configure after strip-flags: > > use pax_kernel && append-flags -nopie Thanks Mark, this worked!
Upstream bug: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18780 (In reply to David Holm from comment #14) > > use pax_kernel && append-flags -nopie > > Thanks Mark, this worked! Can you do one more test, does adding the following line (instead of the above append-flags) work, too? filter-flags -pie
(In reply to Ulrich Müller from comment #15) > Can you do one more test, does adding the following line (instead of the > above append-flags) work, too? > > filter-flags -pie It works as well. I also checked my GCC config and it was indeed set to the wrong toolchain. I removed `filter-flags` and rebuilt using `x86_64-pc-linux-gnu-4.8.3-hardenednopiessp` and that worked too.
Fixed without revbump. Thank you for reporting.
*** Bug 528498 has been marked as a duplicate of this bug. ***
*** Bug 494316 has been marked as a duplicate of this bug. ***
