hdparm Makefile defines its own strip ... STRIP ?= strip ... hdparm: Makefile hdparm.h sgio.h $(OBJS) $(CC) $(LDFLAGS) -o hdparm $(OBJS) $(STRIP) hdparm ... ebuild attempts to disable it by exporting strip as no-op src_configure() { tc-export CC export STRIP=: } but that breaks the post-build strip step in portage because it confuses the tool selection strip: strip --strip-unneeded -N __gentoo_check_ldflags__ -R .comment -R .GCC.command.line -R .note.gnu.gold-version strip: Unable to recognise the format of the input file `/build/cherry/tmp/portage/sys-apps/hdparm-9.65/image/sbin/hdparm'
heh, I hit something like this the other day too. I feel like we should really detect cases like this - if ebuilds want to disable stripping by the PM, they should use dostrip -x or RESTRICT="strip" anyway, so there's no reason for the exported STRIP by the ebuild to persist into what Portage does later, I think?
Hi Sam, I am not that knowledgeable about portage, so I am not sure what would be the right way to address it generically. Here is my take on the specific hdparm issue, suggested by an internal expert: https://github.com/gentoo/gentoo/pull/32718 Let me know if this is an appropriate solution.
(In reply to Sam James from comment #1) > heh, I hit something like this the other day too. > > I feel like we should really detect cases like this - if ebuilds want to > disable stripping by the PM, they should use dostrip -x or RESTRICT="strip" > anyway, so there's no reason for the exported STRIP by the ebuild to persist > into what Portage does later, I think? I don't think this is what this is about, STRIP=: is just trying to prevent stripping so portage can do it -- you know the usual. Not prevent stripping altogether. That aside I don't understand the issue, I do not run into any unrecognized format issues.
(In reply to Ionen Wolkens from comment #3) > That aside I don't understand the issue, I do not run into any unrecognized > format issues. Either way, exporting STRIP is not a great way to prevent it -- this does belong better on the emake line if possible.
yeah, definitely - and I don't get how it's actually happening here, maybe I'm just rambling about something else I was wondering about (if STRIP should survive if exported by ebuild) I can't reproduce it with the ebuild as it is. My guess is it's the same sort of issue, but the Gentoo ebuild as-is can't hit it. But the fix is still fine / a good idea like ionen says.
Oh ok, wording been confusing me. Not that I have issues emerging it on a llvm profile right now (maybe need some custom CFLAGS), but it does use strip(1) rather than my exported llvm-strip with this export STRIP=: -- which is not good.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ea693b93b97f68109c3c19a83d410ca5b3c73080 commit ea693b93b97f68109c3c19a83d410ca5b3c73080 Author: Daniil Lunev <dlunev@google.com> AuthorDate: 2023-09-10 23:03:31 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-09-10 23:48:35 +0000 sys-apps/hdparm: fix post-build strip Export STRIP only for emake step, to avoid confusing portage's strip step. - strip: strip --strip-unneeded -N __gentoo_check_ldflags__ -R .comment -R .GCC.command.line -R .note.gnu.gold-version + strip: llvm-strip --strip-unneeded -N __gentoo_check_ldflags__ -R .comment -R .GCC.command.line -R .note.gnu.gold-version /sbin/hdparm -strip: Unable to recognise the format of the input file `/build/cherry/tmp/portage/sys-apps/hdparm-9.65/image/sbin/hdparm' [sam: I can't reproduce STRIP=: failing but the issue is clear here anyway, we don't want to interfere with the environment's STRIP (even if maybe Portage should ignore ebuild tampering with it). Just do the cleaner thing which makes the ebuild simpler as a bonus.] Closes: https://bugs.gentoo.org/913959 Signed-off-by: Daniil Lunev <dlunev@google.com> Closes: https://github.com/gentoo/gentoo/pull/32718 Signed-off-by: Sam James <sam@gentoo.org> sys-apps/hdparm/hdparm-9.65-r1.ebuild | 45 +++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+)
