Summary: | sci-libs/pdal-2.4.3 fails to compile (lto): BacktraceUnwind.cpp:64:11: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Agostino Sarubbo <ago> |
Component: | Current packages | Assignee: | Thomas Bettler <thomas.bettler> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | proxy-maint, sam, sci-geosciences |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://github.com/PDAL/PDAL/issues/3836 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 618550 | ||
Attachments: |
build.log
build.log |
Description
Agostino Sarubbo
2022-08-02 06:59:11 UTC
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(-) |