https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: x11-misc/i3lock-color-2.13.4 fails to compile (lto). Discovered on: amd64 (internal ref: guru_tinderbox) NOTE: This machine uses lto with CFLAGS=-flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing
Created attachment 794144 [details] build.log build log and emerge --info
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
Hello Lin, please make sure that your email address you are using for commits is the same reported in bug 750821 otherwise it looks to be impossible assign bugs. Thanks
I reported this bug to upstream yesterday, no response so far.
Upstream has been fixed this issue. Change will be included in the next release (2.13.c.5)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/proj/guru.git/commit/?id=da22545eeb393eeb55658e2479be1f6ffcc6ab3f commit da22545eeb393eeb55658e2479be1f6ffcc6ab3f Author: Takuya Wakazono <pastalian46@gmail.com> AuthorDate: 2024-02-05 10:03:30 +0000 Commit: Takuya Wakazono <pastalian46@gmail.com> CommitDate: 2024-02-05 10:04:20 +0000 x11-misc/i3lock-color: add 2.13.5 Closes: https://bugs.gentoo.org/860849 Signed-off-by: Takuya Wakazono <pastalian46@gmail.com> x11-misc/i3lock-color/Manifest | 1 + .../files/i3lock-color-2.13.5-cleanup-cflags.patch | 11 +++++ .../i3lock-color-2.13.5-disable-automagic.patch | 35 +++++++++++++ x11-misc/i3lock-color/i3lock-color-2.13.5.ebuild | 57 ++++++++++++++++++++++ 4 files changed, 104 insertions(+)
