As discussed in bug #465238#c3: In configure.ac: AC_CHECK_DECL([ELF_C_RDWR_MMAP],[],[],[[#include <libelf.h>]]) AM_CONDITIONAL([BUILD_ELF],[test "x$ac_cv_have_decl_ELF_C_RDWR_MMAP" = "xyes"]) Then, in src/Makefile.am: if BUILD_ELF sbin_PROGRAMS += fix-gnustack fix_gnustack_SOURCES = fix-gnustack.c endif This is a bummer, as "emerge -eu @system" on a fresh stage3 with USE=-ptpax requires subsequent "emerge @preserved-rebuild". I suggest skipping installation of fix-gnustack, in case it was built, for USE=-ptpax.
> This is a bummer, as "emerge -eu @system" on a fresh stage3 with USE=-ptpax > requires subsequent "emerge @preserved-rebuild". When dev-libs/elfutils is masked, of course.
Okay with me. Can you make this into a patch against git/HEAD at http://git.overlays.gentoo.org/gitweb/?p=proj/elfix.git;a=summary so i can give proper credits ;)
Created attachment 381866 [details, diff] 0001-Building-fix-gnustack-is-now-conditional-on-enable-p.patch Suggested patch is attached -- hopefully I didn't do something silly, as I have no experience with autoconf.
(In reply to Maxim Kammerer from comment #3) > Created attachment 381866 [details, diff] [details, diff] > 0001-Building-fix-gnustack-is-now-conditional-on-enable-p.patch > > Suggested patch is attached -- hopefully I didn't do something silly, as I > have no experience with autoconf. Your patch looses the decl check for ELF_C_RDWR_MMAP which is important since without mmap support on ELFs (which elfutils provides but libelf does not) you won't be able to update the program headers. Also look at how I changed the commit message. I've put this in and there will be a bump to elfix in a day or so, but I don't think this is the right way to proceed. It is entirely possible that someone wants -ptpax but still needs to remove W from PT_GNU_STACK. I think the correct solution would be to break the tools out. elfix-0.9 will either move fix-gnustack to misc and add a separate package for it in portage, or it will add another switch for it.
(In reply to Anthony Basile from comment #4) > Your patch looses the decl check for ELF_C_RDWR_MMAP which is important > since without mmap support on ELFs (which elfutils provides but libelf does > not) you won't be able to update the program headers. I assumed the extra test was unnecessary because of the inner AS_IF prior to that line, which would fail configure with: [AC_MSG_ERROR(["Missing necessary DECL ELF_C_RDWR_MMAP in libelf"])] when the user tries to enable ptpax without ELF_C_RDWR_MMAP available. It's also what happened when I tested the patched elfix with dev-libs/libelf, when not supplying --disable-ptpax. > I've put this in and there will be a bump to elfix in a day or so, but I > don't think this is the right way to proceed. It is entirely possible that > someone wants -ptpax but still needs to remove W from PT_GNU_STACK. I think > the correct solution would be to break the tools out. elfix-0.9 will either > move fix-gnustack to misc and add a separate package for it in portage, or > it will add another switch for it. Well, it was already clear in bug #465238 that conditioning fix-gnustack on enable-ptpax is a non-ideal solution, this bug only concerns the immediate issue of automagic dependency. :)
(In reply to Maxim Kammerer from comment #5) > (In reply to Anthony Basile from comment #4) > > Your patch looses the decl check for ELF_C_RDWR_MMAP which is important > > since without mmap support on ELFs (which elfutils provides but libelf does > > not) you won't be able to update the program headers. > > I assumed the extra test was unnecessary because of the inner AS_IF prior to > that line, which would fail configure with: > [AC_MSG_ERROR(["Missing necessary DECL ELF_C_RDWR_MMAP in libelf"])] > when the user tries to enable ptpax without ELF_C_RDWR_MMAP available. > > It's also what happened when I tested the patched elfix with > dev-libs/libelf, when not supplying --disable-ptpax. > > > I've put this in and there will be a bump to elfix in a day or so, but I > > don't think this is the right way to proceed. It is entirely possible that > > someone wants -ptpax but still needs to remove W from PT_GNU_STACK. I think > > the correct solution would be to break the tools out. elfix-0.9 will either > > move fix-gnustack to misc and add a separate package for it in portage, or > > it will add another switch for it. > > Well, it was already clear in bug #465238 that conditioning fix-gnustack on > enable-ptpax is a non-ideal solution, this bug only concerns the immediate > issue of automagic dependency. :) I refactored the tree. fix-gnustack is now separated out. I'll write the ebuild and put it on the tree tomorrow. After that, new versions of elfix-0.9 will have only paxctl-ng and friends.
