https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: dev-libs/userspace-rcu-0.13.2 passed test suite but did not execute any tests. 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 802105 [details] build.log build log and emerge --info
Add to src_prepare before eautoreconf: # exclude regtest targets from default tests sed -i '0,/ benchmark regression/{s/ benchmark regression//}' tests/Makefile.am || die This is semantically the same; the the tests under tests/regression are already run by our explicit call to "emake regtest", and the tests under tests/benchmark were not being run anyway, seeing as how they are, well, benchmarks and not actual tests.
(In reply to matoro from comment #2) > Add to src_prepare before eautoreconf: > > # exclude regtest targets from default tests > sed -i '0,/ benchmark regression/{s/ benchmark regression//}' > tests/Makefile.am || die > > > This is semantically the same; the the tests under tests/regression are > already run by our explicit call to "emake regtest", and the tests under > tests/benchmark were not being run anyway, seeing as how they are, well, > benchmarks and not actual tests. It might be better for us to just drop the 'default' call instead so we never even try to run those targets. However, yeah, we could do this fine, as we're already calling eautoreconf in the ebuild, it just might not always be an option.
(In reply to Sam James from comment #3) > (In reply to matoro from comment #2) > > Add to src_prepare before eautoreconf: > > > > # exclude regtest targets from default tests > > sed -i '0,/ benchmark regression/{s/ benchmark regression//}' > > tests/Makefile.am || die > > > > > > This is semantically the same; the the tests under tests/regression are > > already run by our explicit call to "emake regtest", and the tests under > > tests/benchmark were not being run anyway, seeing as how they are, well, > > benchmarks and not actual tests. > > It might be better for us to just drop the 'default' call instead so we > never even try to run those targets. > > However, yeah, we could do this fine, as we're already calling eautoreconf > in the ebuild, it just might not always be an option. You could also do that, in which case replace it with: emake -C tests/utils check emake -C tests/common check emake -C tests/unit check emake -C tests/regression regtest Problem is this is fragile in the event they add more directories under tests/ in later versions...
