Add USES=elfctl to change an ELF binary's feature control note.
Example:
USES= elfctl
ELF_FEATURES= +noaslr,wxneeded:bin/zip
Differential D34125
Mk/Uses: Add elfctl jrm on Feb 1 2022, 2:42 AM. Authored by Tags None Referenced Files
Details
Add USES=elfctl to change an ELF binary's feature control note. Example: USES= elfctl
Diff Detail
Event TimelineComment Actions This is at a WIP/POC stage. I've done some light testing. Is this simpler than documentation suggesting something like this? post-install: elfctl -e +aslr ${STAGEDIR}${PREFIX}/bin/${PORTNAME} # after 12.x is EOL, this can be changed to '+noaslr'. See src/f56d7f838f5b Comment Actions I originally wanted something like this review based on the assumption that we'd need this in a relatively large number of ports, and there would be a lot of value in doing it in a standardized way. In reality it seems that the need for this will be much more limited than I expected, and just documenting use of elfctl in a post-install may well be sufficient - I'll leave that decision to folks who have background/understanding of ports infrastructure. Comment Actions For general infrastructure, I think you want it to be post-build not post-install because test targets may run on the build tree binary. I like USES because it provides explicit documentation of what's happening in a machine parsable way. Comment Actions Set the feature flags post-build, because test targets may run on build tree binaries. Comment Actions @brooks The calls to elfctl are happening in post-build, but I don't think it is straightforward to both 1. set the feature flags on the binaries under the build-tree and 2. have these binaries installed to ${STAGEDIR}. Comment Actions Make the order in each ELF_FEATURES entry featurelist then binary like the elfctl command itself. Comment Actions So either you need to change things so paths are relative to ${BUILD_WRKSRC} or revert to the previous case of doing this post-install. Once flags are applied to the build binaries stage should install them, but the result is a bit ugly. Maybe my suggestion wasn't good and we should wait to see if there is a need to run elfctl on things in BUILD_WRKSRC in practice. Comment Actions I had already tried doing things post-build and pointing elfctl to the binaries under ${BUILD_WRKSRC}. The outcome is often that the binaries in ${BUILD_WRKSRC} are updated, but not those under ${STAGEDIR}. This is because binaries are often staged at the end of the build stage. In other words, post-build and post-install make no difference, so I think we are unfortunately forced to point elfctl to the staged binaries. I'll spend some more time to be certain that it is indeed difficult to modify the binaries under ${BUILD_SRC}, but also have these modified binaries staged.
Comment Actions I don't think ${STAGEDIR} should even exist when post-build runs so I'm a bit confused. IMO ending the build phase with a ${STAGEDIR} is a bug. Comment Actions You're right. I'm wrong. I had been testing with mail/notmuch and when elfct was run on the binary under ${BUILD_WRKSRC} in the post-build[0] target, the resulting binary in ${STAGEDIR} would not be modified. To confirm my suspicion that things were already staged, I added find ${STAGEDIR} * in the post-build[0] target. The output of find showed thing were indeed already staged. What was actually going on was that I was still running elfctl in post-install, because I was still setting _USES_install+=.... Sorry for the confusion. The current code does what you were requesting. [0] What I thought was post-build, but was actually post-install.
|