https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: dev-libs/hiredis-1.0.2-r2 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 801448 [details] build.log build log and emerge --info
Error(s) that match a know pattern: #41 Don't reset state after protocol error: PASSED
The log doesn't contain anything to imply the tests fail due to LTO. Indeed, tests fail with or without LTO in local testing with the same issue. The later version of hiredis has a more obvious messaging about it: Testing asynchronous API against TCP connection (127.0.0.1:0): Connection error: Connection refused
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2799cb060ccd96724ef5f627ce94ab74547de2b9 commit 2799cb060ccd96724ef5f627ce94ab74547de2b9 Author: Petr Vaněk <arkamar@gentoo.org> AuthorDate: 2024-04-19 09:19:14 +0000 Commit: Petr Vaněk <arkamar@gentoo.org> CommitDate: 2024-04-19 09:35:47 +0000 dev-libs/hiredis: correct hiredis-test parameter The -p parameter expects redis port, not PID. Tests still fail, but those issues were fixed in version 1.1.0, which is about to be stabilized, therefore, I don't think we have to spend time fixing them. Failures are most probably related to used redis server version, see comments in [1]. [1] https://github.com/redis/hiredis/commit/b455b33818be4dab51777433fcac0d15e0c221ec Closes: https://bugs.gentoo.org/864795 Closes: https://bugs.gentoo.org/866944 Closes: https://bugs.gentoo.org/880395 Signed-off-by: Petr Vaněk <arkamar@gentoo.org> dev-libs/hiredis/hiredis-1.0.2-r3.ebuild | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
