https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: app-crypt/tpm2-abrmd-2.4.1-r1 fails tests (lto). Discovered on: amd64 (internal ref: lto_tinderbox) NOTE: This machine uses lto with CFLAGS=-flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing Here is a bit of explanation: -Werror=lto-type-mismatch: User to find possible runtime issues in packages. It likely means the package is unsafe to build & use with LTO. For projects using the same identifier but with different types across different files, they must be fixed to be consistent across the codebase. -Werror=odr: Used to find possible runtime issues in packages. These bugs are a problem anyway but may be even worse when combined with LTO. C++ code must comply with the One Definition Rule (ODR) - see https://en.cppreference.com/w/cpp/language/definition#One_Definition_Rule. -Werror=strict-aliasing: Used to find possible runtime issues in packages. These bugs are a problem anyway but may be even worse when combined with LTO. Workarounds: - If upstream is friendly and still active, file a bug upstream. For emulators, codecs, games, or multimedia packages, it may be worth just applying a workaround instead, as upstreams sometimes aren't receptive to these bugs (VALID FOR ALL). - Use the new 'filter-lto' from flag-o-matic.eclass as it's likely to be unsafe with LTO (VALID FOR lto-type-mismatch - odr). - Fix it yourself if interested, of course (VALID FOR ALL). - Append-flags -fno-strict-aliasing (VALID FOR strict-aliasing). - Use memcpy() but a union is sometimes suitable too (VALID FOR strict-aliasing). - -fstrict-aliasing is implied by -O2, so this must be addressed in some form (VALID FOR strict-aliasing). See also: https://marc.info/?l=gentoo-dev&m=165639574126280&w=2
Created attachment 799773 [details] build.log build log and emerge --info
Error(s) that match a know pattern in addition to what has been reported in the summary: <artificial>:(.text+0x175): undefined reference to `__wrap_tcti_tabrmd_call_cancel_sync' <artificial>:(.text+0x25a): undefined reference to `__wrap_tcti_tabrmd_call_set_locality_sync' <artificial>:(.text+0x4c6): undefined reference to `__wrap_set_logger' <artificial>:(.text+0xf03): undefined reference to `__wrap_tcti_tabrmd_proxy_new_for_bus_sync' collect2: error: ld returned 1 exit status
Well, this one's complicated. It appears to be an interaction between cmocka (used in tests), gcc and ld.bfd (the problem is even worse under ld,gold). clang/ld.lld is not affected and compiles file (but clang/ld.bfd is) I have a feeling that any program uses gcc/ld.bfd/cmocka is going to run into this problem. filter-lto does not work src_test with autotools at least, and I'm not sure what the best option is going forward.
How did you try to use "filter-flto"? I imagine you have to use it in src_configure, "if use test;" and remember to inherit flag-o-matic.eclass.
Something like "use test && filter-lto" in src_compile would work, but it would have the undesirable side effect of disabling LTO on the whole package, when only the tests need it disabled.
Sounds totally fine to me. Doubt many regular users have tests turned on for ebuilds.
(In reply to Joonas Niilola from comment #6) > Sounds totally fine to me. Doubt many regular users have tests turned on for > ebuilds. The issue is that you then have no idea if LTO is breaking something at runtime. Just filter lto unconditionally until tests work and add a comment saying such.
(In reply to Sam James from comment #7) > > The issue is that you then have no idea if LTO is breaking something at > runtime. ... isn't that the default presumption when lto is turned on? :) but yeah don't mind turning it completely off either, that's probably the simplest and surest option here.
(In reply to Joonas Niilola from comment #8) > (In reply to Sam James from comment #7) > > > > The issue is that you then have no idea if LTO is breaking something at > > runtime. > > ... isn't that the default presumption when lto is turned on? :) but yeah > don't mind turning it completely off either, that's probably the simplest > and surest option here. The whole idea of this work is to try find things which are likely to be broken at runtime and prevent it. If we have the tests failing with LTO for any reason, then we have to assume it's not safe.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b37aeca1bcdac3de7c1be1229ad0960c9be88b83 commit b37aeca1bcdac3de7c1be1229ad0960c9be88b83 Author: Christopher Byrne <salah.coronya@gmail.com> AuthorDate: 2022-09-26 21:08:48 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-09-27 21:42:35 +0000 app-crypt/tpm2-abrmd: Filter out LTO flags due test failures Closes: https://bugs.gentoo.org/865275 Signed-off-by: Christopher Byrne <salah.coronya@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> app-crypt/tpm2-abrmd/tpm2-abrmd-2.4.1-r1.ebuild | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
