https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: games-engines/odamex-10.0.0 fails to compile (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
Created attachment 792080 [details] build.log.xz build log and emerge --info (compressed because it exceeds attachment limit, use 'xzless' to read it)
Error(s) that match a know pattern in addition to what has been reported in the summary: FAILED: client/CMakeFiles/odamex.dir/src/cl_parse.cpp.o /var/tmp/portage/games-engines/odamex-10.0.0/work/odamex-src-10.0.0/client/src/cl_parse.cpp:2287:26: error: dereferencing type-punned pointer will break strict-aliasing rules [-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
This package version is no longer available in portage. This bug may be a candidate for closure.
(In reply to Mike Wood from comment #4) > This package version is no longer available in portage. This bug may be a > candidate for closure. Have you checked if the bug still applies to the newer version (tried to reproduce)?
Created attachment 874922 [details] build log compressed with xz Still reproducible on 10.4.0 /var/tmp/portage/games-engines/odamex-10.4.0/work/odamex-src-10.4.0/client/src/cl_parse.cpp:2357:26: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] 2357 | *(int*)§or->gravity = msg->sector().gravity(); | ^~~~~~~~~~~~~~~~~~~~~~
(In reply to Sam James from comment #5) > (In reply to Mike Wood from comment #4) > > This package version is no longer available in portage. This bug may be a > > candidate for closure. > > Have you checked if the bug still applies to the newer version (tried to > reproduce)? To be clear, I had no reason to believe it was fixed, and I suspected they were just asking because the exact version was no longer in tree.
Could you please report the bug to upstream too? Thanks
lto_tinderbox has reproduced this issue with version 10.4.0-r1 - Updating summary.
https://github.com/odamex/odamex/pull/673 isn't a complete fix but it's partial. https://github.com/odamex/odamex/blob/f9e399a3a8c04de2fee40cd6a1d9749d116a5b5a/client/src/cl_parse.cpp#L2357 is still there.
There are actually 3 aliasing issues. I've fixed them up, and they seem to work fine, but I am unsure, so I'll run them by upstream before committing anything here. Somewhat depressingly, the package is rather broken anyway. Someone outside the games team took it upon themselves to bump it to wxGTK 3.2 when that causes odalaunch to crash. I'd previously made the same mistake myself, but at least I'm on the team! Trying to join a server from odalaunch also doesn't work because it uses the wrong path. I'll get these fixed up too.
I'd appreciate some extra eyes over my changes, as I've not tried to fix this kind of issue before.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9f8fd17d55d0fe0cbca82eda3464338508b6bf25 commit 9f8fd17d55d0fe0cbca82eda3464338508b6bf25 Author: James Le Cuirot <chewi@gentoo.org> AuthorDate: 2024-03-19 23:03:42 +0000 Commit: James Le Cuirot <chewi@gentoo.org> CommitDate: 2024-03-19 23:03:42 +0000 games-engines/odamex: Fix launcher path issue, fix LTO, fix wxGTK crash We've already seen that odalaunch crashes with wxGTK 3.2 so keep it at 3.0. I have looked into this, and it relates to the server list sorting, but I cannot figure it out. Closes: https://bugs.gentoo.org/858722 Signed-off-by: James Le Cuirot <chewi@gentoo.org> games-engines/odamex/files/odamex-lto.patch | 41 ++++++++++++++ .../odamex/files/odamex-odalaunch-prefix.patch | 64 ++++++++++++++++++++++ ...ex-10.4.0-r1.ebuild => odamex-10.4.0-r2.ebuild} | 6 +- 3 files changed, 109 insertions(+), 2 deletions(-)
