https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: net-fs/openafs-1.8.8.1-r1 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 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 794693 [details] build.log.xz build log and emerge --info (compressed because it exceeds attachment limit, use 'xzless' to read it)
I think LTO should be filtered in openafs until upstream will officially support it: it's build process is very delicate, maybe LTO can be used for some parts, but definitely not for the whole package.
Cheyenne, do you know it upstream has any plans on LTO? Looks like this will require non-trivial changes.
(In reply to Andrew Savchenko from comment #3) > Cheyenne, do you know it upstream has any plans on LTO? Looks like this will > require non-trivial changes. I took a quick stab at turning on LTO.. and yes -- it's going require some non-trivial changes. At the moment I'm thinking of maybe trying to run LTO in warning instead of error mode and see if there are any "easy" fixes. I believe that one of the LTO related errors involved some code that should be going away as it's dead code.. but that gerrit is still pending in review. In the meantime, I would filter out LTO for openafs.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2f4838d48730805078e00bd26722480e9c54a561 commit 2f4838d48730805078e00bd26722480e9c54a561 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-03-12 03:23:11 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-03-12 03:30:51 +0000 net-fs/openafs: filter LTO As recommended by an upstream contributor (albeit 2 years ago...) Closes: https://bugs.gentoo.org/861368 Signed-off-by: Sam James <sam@gentoo.org> net-fs/openafs/openafs-1.8.7.ebuild | 3 +++ net-fs/openafs/openafs-1.8.8.1-r1.ebuild | 3 +++ 2 files changed, 6 insertions(+)
