Created attachment 462226 [details] full build log /bin/mkdir -p ../etc setfattr -n user.pax.flags -v er temacs make -C ../lisp update-subdirs make[2]: Entering directory '/var/tmp/portage/app-editors/emacs-25.1/work/emacs-25.1/lisp' for file in . ./calc ./calendar ./emacs-lisp ./emulation ./erc ./eshell ./gnus ./international ./language ./mail ./mh-e ./net ./nxml ./obsolete ./org ./play ./progmodes ./term ./textmodes ./url ./vc; do \ ./../build-aux/update-subdirs $file; \ done; make[2]: Leaving directory '/var/tmp/portage/app-editors/emacs-25.1/work/emacs-25.1/lisp' ./temacs --batch --load loadup bootstrap make[1]: *** [Makefile:737: bootstrap-emacs] Segmentation fault make[1]: Leaving directory '/var/tmp/portage/app-editors/emacs-25.1/work/emacs-25.1/src' make: *** [Makefile:398: src] Error 2 [31;01m*[0m ERROR: app-editors/emacs-25.1::gentoo failed (compile phase): [31;01m*[0m emake failed [31;01m*[0m [31;01m*[0m If you need support, post the output of `emerge --info '=app-editors/emacs-25.1::gentoo'`, [31;01m*[0m the complete build log and the output of `emerge -pqv '=app-editors/emacs-25.1::gentoo'`. [31;01m*[0m The complete build log is located at '/var/tmp/portage/app-editors/emacs-25.1/temp/build.log'. [31;01m*[0m The ebuild environment file is located at '/var/tmp/portage/app-editors/emacs-25.1/temp/environment'. [31;01m*[0m Working directory: '/var/tmp/portage/app-editors/emacs-25.1/work/emacs-25.1' [31;01m*[0m S: '/var/tmp/portage/app-editors/emacs-25.1/work/emacs-25.1'
Created attachment 462228 [details] emerge --info output Looks similar to those bugs for older versions of emacs: https://bugs.gentoo.org/show_bug.cgi?id=285778 and https://bugs.gentoo.org/show_bug.cgi?id=456970
What are the values of XATTR_PAX_FLAGS and PT_PAX_FLAGS in your kernel configuration?
I'm seeing the same error, and I have: # grep PAX_FLAGS /boot/config-$(uname -r) CONFIG_PAX_PT_PAX_FLAGS=y CONFIG_PAX_XATTR_PAX_FLAGS=y # grep PAX /etc/portage/make.conf PAX_MARKINGS="XT PT" # paxctl-ng -v /var/tmp/portage/app-editors/emacs-25.1/work/emacs-25.1/src/temacs /var/tmp/portage/app-editors/emacs-25.1/work/emacs-25.1/src/temacs: PT_PAX : -e--- XATTR_PAX : -e-r- If I disable all PaX flags on temacs: # paxctl-ng -pemrs /var/tmp/portage/app-editors/emacs-25.1/work/emacs-25.1/src/temacs and continue the build, it completes successfully: # ebuild /usr/portage/app-editors/emacs/emacs-25.1.ebuild compile [...] >>> Compiling source in /var/tmp/portage/app-editors/emacs-25.1/work/emacs-25.1 ... [...] ./temacs --batch --load loadup bootstrap Loading loadup.el (source)... [...] >>> Source compiled.
(In reply to Karl-Johan Karlsson from comment #3) > I'm seeing the same error, and I have: > > # grep PAX_FLAGS /boot/config-$(uname -r) > CONFIG_PAX_PT_PAX_FLAGS=y > CONFIG_PAX_XATTR_PAX_FLAGS=y According to the hardened team, this is not a supported configuration, see bug 497498 comment #13.
(In reply to Ulrich Müller from comment #4) > According to the hardened team, this is not a supported configuration, see > bug 497498 comment #13. Ulrich, I understand that the problem does not reside in emacs, but the fact is that the auto config for grsecurity enables both. So all hardened users will have the same problem.
Created attachment 462772 [details, diff] Revert to paxctl/setfattr logic of Emacs 24.5. (In reply to Agostino Sarubbo from comment #5) > I understand that the problem does not reside in emacs, but the fact is that > the auto config for grsecurity enables both. I wonder why that is so, because when asking I was told this: <ulm> is PT_PAX_FLAGS _and_ XATTR_PAX_FLAGS a supported configuration? <Zorry> you should only use one of them <Zorry> and the missmatch check in the kernel i think is removed in newer kernel or set softer <ulm> Zorry: do you know since what kernel version? <Zorry> i think it was 3.12.6-r2 <blueness> ulm, as Zorry said, use only one Anyway, please try if attached patch fixes the problem.
CCing hardened team. Can you please comment if enabling both of CONFIG_PAX_PT_PAX_FLAGS and CONFIG_PAX_XATTR_PAX_FLAGS is a supported configuration? Also I was told in 2014 that PT_PAX_FLAGS would go away at some time. That seems not to be the case?
Consultation in #gentoo-hardened confirmed that only one of PT_PAX and XATTR_PAX should be enabled in the kernel. In fact, the PaX Quickstart Guide https://wiki.gentoo.org/wiki/Hardened/PaX_Quickstart says: "One final caveat about the two supported methods of doing PaX markings: the PaX kernel allows both PT_PAX and XATTR_PAX to be enabled, however if both features have been enabled PaX will not impose the markings unless the same flags are found in both locations. For this reason, the Hardened Project not recommend enabling both features at the same time, even for migration which is described below." The two example kernel configurations that follow below this each have only one of the two options enabled. So I tend to close this bug as INVALID again. I'll also change the build-time dependency to depend only on one of sys-apps/attr and sys-apps/paxctl. That is, unless someone comes up with a compelling reason why we should revert the Emacs build system to use both setfattr and paxctl (and confirms that the patch from attachment 462772 [details, diff] works).
(In reply to Ulrich Müller from comment #8) > So I tend to close this bug as INVALID again. I'll also change the > build-time dependency to depend only on one of sys-apps/attr and > sys-apps/paxctl. > > That is, unless someone comes up with a compelling reason why we should > revert the Emacs build system to use both setfattr and paxctl (and confirms > that the patch from attachment 462772 [details, diff] [details, diff] works). You should just use the pax-utils eclass which will set things properly according to what the user has set in make.conf and fall back to other tools to mark with if the best arnt available. dont just use only one of them.
(In reply to Jason Zaman from comment #9) > You should just use the pax-utils eclass which will set things properly > according to what the user has set in make.conf and fall back to other tools > to mark with if the best arnt available. dont just use only one of them. Sorry, but that won't work. PaX marking is done purely as an intermediate step during the build process, before the final emacs binary is dumped. The files that are being installed don't need any PaX settings, therefore pax-utils.eclass won't help there.
(In reply to Ulrich Müller from comment #10) > (In reply to Jason Zaman from comment #9) > > You should just use the pax-utils eclass which will set things properly > > according to what the user has set in make.conf and fall back to other tools > > to mark with if the best arnt available. dont just use only one of them. > > Sorry, but that won't work. PaX marking is done purely as an intermediate > step during the build process, before the final emacs binary is dumped. The > files that are being installed don't need any PaX settings, therefore > pax-utils.eclass won't help there. Oh, in that case use edit the makefile to use /usr/sbin/paxmark.sh (from sys-apps/elfix) instead. Its designed for that case and it implements all the same fallback logic as the eclass.
We clarified that this is an unsupported configuration. So this can be closed as invalid.
*** Bug 622146 has been marked as a duplicate of this bug. ***
