The currently used patches (all-3 and mpi8-small) are rather out-of-date and missing a lot of recent updates. I've submitted a revised MPI patch that is compatible with the all-5 jumbo patchset, and took the time to make the following updates to the ebuild: - update patches to all-5 and mpi10 - remove outdated pkg_setup() warning - re-tooled stackdef.S patch to match default package - added all-5 stackdef.S patch to fix the ASM introduced with the jumbo patch - removed params.h patch (unnecessary, breaks prefix portage, see bug 265316) - brought in the cflags patch & LDFLAGS fixes from prefix - changed PIC/PIE flags (produced textrel in x86-hardened, tested in ~x86-hardened, ~amd64-hardened, and ~amd64) - added SYSTEMWIDE_EXEC define from prefix and made both defines ${ROOT} sensitive - updated src_install for new tools in all-5 Patches forthcoming; the only x86 system I've not tested this on is 32-bit non-hardened.
Created attachment 197922 [details, diff] diff against current ebuild
Created attachment 197924 [details] 1.7.3.1-r1 full ebuild
Created attachment 197925 [details, diff] stackdefs for all-5
Created attachment 197927 [details, diff] cflags patch from prefix
Created attachment 197928 [details, diff] updated stackdef.S patch
Created attachment 201817 [details, diff] stackdefs for all-5 (v2) Updated stackdef-all-5 patch, hadn't tested this on an MMX build yet. This bug should be a quick win, updating and knocking out bugs at the same time.
Could you send this patch to upstream?
All the attached patches are Gentoo artifacts, and I've actually removed one from Gentoo's normal distribution since it was unnecessary and broke gentoo-prefix (params.h). In a general sense, none of the patches fix anything that's broken, they only force JtR to fit within the Gentoo worldview. The two stackdef.S patches are split from the original single one so they could be applied appropriately (according to USE=minimal). The cflags patch is from gentoo-prefix and could be dropped, but for what it does seems petty to refuse an update for it. To reiterate, I'm only fixing what is already there. I will contact Solar Designer and see whether he's interested in incorporating the sandbox and CFLAG patches, but the upstream release cycle has sufficiently slowed that incorporation in any reasonable timescale is highly unlikely, if he even accepts them.
+ 03 Sep 2009; Patrick Lauer <patrick@gentoo.org> + +johntheripper-1.7.3.1-r1.ebuild, + +files/johntheripper-1.7.3.1-all-5-stackdef.S.patch, + +files/johntheripper-1.7.3.1-cflags.patch, + files/johntheripper-1.7.3.1-stackdef.S.patch: + Small set of fixes, thanks to RB. Closes #277811
CPP=${CPP} CC=${CC} AS=${AS} LD=${LD} \ - CFLAGS="-c -Wall ${CFLAGS} -DJOHN_SYSTEMWIDE -DJOHN_SYSTEMWIDE_HOME=\"\\\"/etc/john\\\"\"" \ + CFLAGS="-c -Wall ${CFLAGS} -DJOHN_SYSTEMWIDE -DJOHN_SYSTEMWIDE_HOME=\"\\\"${ROOT}/etc/john\\\"\" -DJOHN_SYSTEMWIDE_EXEC=\"\\\"${ROOT}/usr/libexec/john\\\"\"" \ LDFLAGS="${LDFLAGS}" \ Hardcoding ROOT inside an application really is no good idea. What made you think it?
(In reply to comment #10) It's unrelated to this bug. Please file a separate bug.
(In reply to comment #10) Anyway we can't use ${ROOT} in src_compile().
maybe I was talking to the original reporter instead?
I removed use of ROOT.
Apologies; that was an artifact from a path I'd taken to being more Prefix-friendly and forgotten to take out.
ah, I see.
