https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: games-emulation/advancemame-3.9 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 791978 [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
Beautiful: dnl Code was written when compilers where not aggressively optimizing undefined behaviour about aliasing dnl WARNING! At present disabled to maximize performance dnl AC_CHECK_CC_OPT([-fno-strict-aliasing], [CFLAGS="$CFLAGS -fno-strict-aliasing"], []) dnl Code was written when compilers where not aggressively optimizing undefined behaviour about overflow in signed integers dnl WARNING! At present disabled to maximize performance dnl AC_CHECK_CC_OPT([-fno-strict-overflow], [CFLAGS="$CFLAGS -fno-strict-overflow"], []) dnl Code was written on Intel where char is signed AC_CHECK_CC_OPT([-fsigned-char], [CFLAGS="$CFLAGS -fsigned-char"], []) "the code is unsafe!" "We're gonna disable the unsafety protector because it doesn't squeeze as much performance out."
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4a0b19c40778736c971a3ef371413404b25ceac0 commit 4a0b19c40778736c971a3ef371413404b25ceac0 Author: Eli Schwartz <eschwartz93@gmail.com> AuthorDate: 2024-03-15 19:42:20 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-03-15 20:21:37 +0000 games-emulation/advancemame: suppress compiler optimizations with fire Upstream configure.ac sets some sanity flags, but only when CFLAGS aren't defined. They acknowledge the codebase was written "when compilers where not aggressively optimizing undefined behaviour". We should respect that even though we do set CFLAGS. Also suppress LTO because why on earth should we assume that will work if they have that much UB. Closes: https://bugs.gentoo.org/858626 Signed-off-by: Eli Schwartz <eschwartz93@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> .../{advancemame-3.9.ebuild => advancemame-3.9-r1.ebuild} | 11 +++++++++++ 1 file changed, 11 insertions(+)
