binutils-2.23.51.0.9+ is now defaulting to hash-style=gnu for ld.{bfd,gold} so the existing QA check won't work. might have to do something with gcc's record switches flag ...
Created attachment 374182 [details, diff] example.patch Was writing a new bug, bug I figured out there's this duplicate; so, copy/paste: The 77_all_generate-gnu-hash.patch patch from Gentoo patchset binutils-2.24-patches-1.3.tar.xz enables GNU_HASH by default for Linux (non-mips) targets; because of this change, the QA check for missing LDFLAGS no longer works. One way to get it the QA check to work again is to switch to the old hash style instead of the new one; that way, checking for the absence will make the check work. Attached is an example of this idea. However, I'm thinking we would need to write a patch that bases itself on the binutils versions in order to properly support the old and the new approach; after everyone has migrated to the newer binutils in the near future, we can then drop the old clause. There are possibly other solutions, the idea / example is a temporary fix to me. (Thanks to Zero_Chaos and ssuominen for helping debug this.)
Maybe better to patch binutils to default to --hash-style=both (i.e. generate both .hash and .gnu.hash).
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #2) the binutils default makes more sense. generating sysv is a waste of disk/memory at runtime.
Hmm, is there perhaps some other low profile flag (upstream almost never uses it + no drawbacks) that we can use to check this instead of changing the hash style? Problem with above question is that would be a search for a needle in a haystack.
Popped up again in -dev ML recently: https://archives.gentoo.org/gentoo-dev/message/07a6d4426de009a32877903142b56f05
Maybe the --build-id flag of ld could be used. It produces a lightweight ".note.gnu.build-id" section.
(In reply to Felix Janda from comment #6) > Maybe the --build-id flag of ld could be used. It produces a lightweight > ".note.gnu.build-id" section. If I understand your suggestion correctly, it would re-introduce bug #526144 (e.g. collisions between many packages).
You are probably right (maybe this has been fixed in portage since then). Anyway, it seems that --build-id is also used for other purposes in gentoo. Next try: Adding something like '--defsym=__gentoo_check_ldflags=0' would produce a dummy symbol in the binary, which could then be detected via 'scanelf -q -s __gentoo_check_ldflags'. This should cause only a very slight size and performance impact on the resulting binaries, however I'm not sure whether this would interact badly with other gentoo tools.
(In reply to Felix Janda from comment #8) > Adding something like '--defsym=__gentoo_check_ldflags=0' would produce > a dummy symbol in the binary, which could then be detected via > 'scanelf -q -s __gentoo_check_ldflags'. > > This should cause only a very slight size ... impact on the > resulting binaries strip tool from sys-devel/binutils probably can remove a specified symbol: $ strip --help | grep -- strip-symbol -N --strip-symbol=<name> Do not copy symbol <name> (Portage also supports strip tool from dev-libs/elfutils which does not have this ability.)
Created attachment 498786 [details, diff] Proposed patch To test, add "-Wl,--defsym=__gentoo_check_ldflags__=0" to your LDFLAGS (and try emerging e.g. media-gfx/jpeg2ps). Note that the symbol added via the ldflags test will be automatically removed when (or if) the binary is stripped.
(In reply to Felix Janda from comment #10) > Created attachment 498786 [details, diff] [details, diff] > Proposed patch Note that comm requires sorted input, so maybe it should be something like this: f=$(comm -3 <(scanelf -qyRF '#k%p' -k .dynsym "${ED}" | LC_ALL=C sort) \ <(scanelf -qyRF '#s%p' -s __gentoo_check_ldflags__ "${ED}"| LC_ALL=C sort))
I've posted the patch for review here: https://archives.gentoo.org/gentoo-portage-dev/message/df7752fc0ee46be44b18f9926afcc5fd https://github.com/gentoo/portage/pull/220
Thanks for fixing and posting the patch! If only scanelf provided a way to match binaries not matching a symbol...
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=730a867c1050937c82c775d7678a616c7b9546e6 commit 730a867c1050937c82c775d7678a616c7b9546e6 Author: Felix Janda <felix.janda@posteo.de> AuthorDate: 2017-10-16 03:51:37 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2017-10-16 17:20:04 +0000 install-qa-check.d/10ignored-flags: fix LDFLAGS check (bug 455232) Since binutils-2.23.51.0.9+ defaults to hash-style=gnu, use a __gentoo_check_ldflags__ symbol instead. The check is now enabled by adding "-Wl,--defsym=__gentoo_check_ldflags__=0" to LDFLAGS. The symbol will be automatically removed when the binary is stripped. Bug: https://bugs.gentoo.org/455232 Acked-by: Brian Dolbec <dolsen@gentoo.org> bin/install-qa-check.d/10ignored-flags | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)}
At some point, the documentation (that is, the devmanual and the wiki pages [1][2][3][4]) should be updated. [1]: https://wiki.gentoo.org/wiki/Project:AMD64_Arch_Testers [2]: https://wiki.gentoo.org/wiki/Project:X86/Arch_Testers_FAQ [3]: https://wiki.gentoo.org/wiki/Paludis/Guide [4]: https://wiki.gentoo.org/wiki/Package_testing
