https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: sci-libs/pdal-2.4.0-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 796762 [details] build.log build log and emerge --info
Error(s) that match a know pattern in addition to what has been reported in the summary: -- Could NOT find LIBEXECINFO (missing: LIBEXECINFO_LIBRARY) FAILED: pdal/util/CMakeFiles/pdal_util.dir/private/BacktraceUnwind.cpp.o /var/tmp/portage/sci-libs/pdal-2.4.0-r1/work/PDAL-2.4.0-src/pdal/util/private/BacktraceUnwind.cpp:64:11: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
THX for reporting this issue. However given the information you provided I was not able to reproduce with said CFLAGS / CXXFLAGS here. It would be helpful if you provide more information how to reproduce. NEEDINFO
Created attachment 798640 [details] build.log successful build log with your CFLAGS / CXXFLAGS
(In reply to Thomas Bettler from comment #3) > It would be helpful if you provide more information how to reproduce. (In reply to Agostino Sarubbo from comment #0) > - -fstrict-aliasing is implied by -O2 The machine uses the mentioned CFLAGS in addition to the system cflags (see the provided emerge --info in the log) so since you missed -O2 you did non enable the strict aliasing.
(In reply to Agostino Sarubbo from comment #5) > (In reply to Agostino Sarubbo from comment #0) > > - -fstrict-aliasing is implied by -O2 > > The machine uses the mentioned CFLAGS in addition to the system cflags (see > the provided emerge --info in the log) so since you missed -O2 you did non > enable the strict aliasing. :)
(In reply to Agostino Sarubbo from comment #5) > (In reply to Thomas Bettler from comment #3) > > It would be helpful if you provide more information how to reproduce. > > (In reply to Agostino Sarubbo from comment #0) > > - -fstrict-aliasing is implied by -O2 > > The machine uses the mentioned CFLAGS in addition to the system cflags (see > the provided emerge --info in the log) so since you missed -O2 you did non > enable the strict aliasing. I suggest the tinderbox report to provide a one-liner on how to reproduce to make such points quickly clear & reproducible :) Something like CFLAGS="..." [...] emerge ... This would obsolete such kind of Q&A :)
(In reply to Sam James from comment #6) > (In reply to Agostino Sarubbo from comment #5) > > (In reply to Agostino Sarubbo from comment #0) > > > - -fstrict-aliasing is implied by -O2 > > > > The machine uses the mentioned CFLAGS in addition to the system cflags (see > > the provided emerge --info in the log) so since you missed -O2 you did non > > enable the strict aliasing. > > :) you're most welcome to take over maintainership :)
(In reply to Thomas Bettler from comment #8) > (In reply to Sam James from comment #6) > > (In reply to Agostino Sarubbo from comment #5) > > > (In reply to Agostino Sarubbo from comment #0) > > > > - -fstrict-aliasing is implied by -O2 > > > > > > The machine uses the mentioned CFLAGS in addition to the system cflags (see > > > the provided emerge --info in the log) so since you missed -O2 you did non > > > enable the strict aliasing. > > > > :) > > you're most welcome to take over maintainership :) ...? It wasn't a snarky thing towards you. I was happy to see ago nailed the issue. It's subtle and easy to miss, it's a good catch.
(and I missed it too at a skim)
(In reply to Sam James from comment #10) > (and I missed it too at a skim) k, thanks for this context then :)
(In reply to Agostino Sarubbo from comment #0) > -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: > [...] > - -fstrict-aliasing is implied by -O2, so this must be addressed in some > form (VALID FOR strict-aliasing). next to my proposition for a simple one-liner to reproduce, let me add that a feedback on the above message. 1. *implied by* commonly has a meaning of *implicated by / enabled by* - whereas in this context the phrasing *requires the use of* would make the point. 2. the message uses both *-Werror=strict-aliasing* and *-fstrict-aliasing*, maybe inconsistently? 3. IMO requires the use of -O2 is worth hinting in the enumeration title, or at your choice somewhere nearby... *-Werror=strict-aliasing: (requires the use of -O2)*
lto_tinderbox has reproduced this issue with version 2.4.3 - Updating summary.
(In reply to Thomas Bettler from comment #12) > (In reply to Agostino Sarubbo from comment #0) > > -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: > > [...] > > - -fstrict-aliasing is implied by -O2, so this must be addressed in some > > form (VALID FOR strict-aliasing). > > > next to my proposition for a simple one-liner to reproduce, let me add that > a feedback on the above message. > > 1. *implied by* commonly has a meaning of *implicated by / enabled by* - > whereas in this context the phrasing *requires the use of* would make the > point. It doesn't though, you can pass -fstrict-aliasing to enable it with -O1. It is just implied by -O2. > > 2. the message uses both *-Werror=strict-aliasing* and *-fstrict-aliasing*, > maybe inconsistently? > No, -fstrict-aliasing does the optimisation (and is on by default at -O2). -Werorr=strict-aliasing tells you when you're doing something bad.
Okay so for a bit of EXTREMELY relevant context, I have been banging my head against this for quite a while now. I can't even find BacktraceUnwind.cpp getting compiled at all... ... turns out it requires building with USE=debug which was NOT mentioned at any point in time.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ffbde6e64183dd733002c25aaa649564c37ff813 commit ffbde6e64183dd733002c25aaa649564c37ff813 Author: Eli Schwartz <eschwartz93@gmail.com> AuthorDate: 2024-03-17 07:09:00 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-03-17 07:49:46 +0000 sci-libs/pdal: mark as LTO-unsafe, strict-aliasing unsafe ... but only for USE=debug, since the bug is inside the obscure libunwind support which most people don't use anyway. Closes: https://bugs.gentoo.org/862915 Signed-off-by: Eli Schwartz <eschwartz93@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> sci-libs/pdal/pdal-2.6.2.ebuild | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
