https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: x11-libs/motif-2.3.8-r3 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 798957 [details] build.log build log and emerge --info
Created attachment 798981 [details, diff] Patch for ebuild Looks like flex output has changed. flex-2.6.4 declares yyleng as int, while flex-2.5.39 declared it as yy_size_t. Removing the generated versions (that are shipped in the tarball) might help. Please try if attached patch fixes the problem.
(In reply to Ulrich Müller from comment #2) > Please try if attached patch fixes the problem. ping
ping
I still see a lot of: ``` /var/tmp/portage/x11-libs/motif-2.3.8-r3/work/motif-2.3.8/lib/Xm/TabStack.c:74:13: warning: type of '_XmTabBoxStackedGeometry' does not match original declaration [-Wlto-type-mismatch] 74 | extern void _XmTabBoxStackedGeometry _ARGS((Widget, int, XRectangle *)); | ^ /var/tmp/portage/x11-libs/motif-2.3.8-r3/work/motif-2.3.8/lib/Xm/TabBox.c:9039:1: note: type mismatch in parameter 2 9039 | _XmTabBoxStackedGeometry(XmTabBoxWidget tab, Dimension size, | ^ /var/tmp/portage/x11-libs/motif-2.3.8-r3/work/motif-2.3.8/lib/Xm/TabBox.c:9039:1: note: type 'Dimension' should match type 'int' /var/tmp/portage/x11-libs/motif-2.3.8-r3/work/motif-2.3.8/lib/Xm/TabBox.c:9039:1: note: '_XmTabBoxStackedGeometry' was previously declared here /var/tmp/portage/x11-libs/motif-2.3.8-r3/work/motif-2.3.8/lib/Xm/TabBox.c:9039:1: note: code may be misoptimized unless '-fno-strict-aliasing' is used /var/tmp/portage/x11-libs/motif-2.3.8-r3/work/motif-2.3.8/lib/Xm/DataFSel.c:89:13: warning: type of '_XmDataFieldDeselectSelection' does not match original declaration [-Wlto-type-mismatch] 89 | extern void _XmDataFieldDeselectSelection(Widget, int, WIDE_PROTOTYPE, Time); | ^ /var/tmp/portage/x11-libs/motif-2.3.8-r3/work/motif-2.3.8/lib/Xm/DataF.c:4219:1: note: type mismatch in parameter 2 4219 | _XmDataFieldDeselectSelection( | ^ /var/tmp/portage/x11-libs/motif-2.3.8-r3/work/motif-2.3.8/lib/Xm/DataF.c:4219:1: note: type 'Boolean' should match type 'int' /var/tmp/portage/x11-libs/motif-2.3.8-r3/work/motif-2.3.8/lib/Xm/DataF.c:4219:1: note: '_XmDataFieldDeselectSelection' was previously declared here lto-wrapper: warning: using serial compilation of 38 LTRANS jobs ``` I think it's reasonable to filter-lto on this, but your patch *does* improve the situation (so is probably worth applying anyway). I don't understand why GCC is warning on those additional instances I quoted above despite -Werror= being passed by me, appearing in the log, and working on other instances like the flex one, but whatever.. (Maybe it differentiates between "might be bad" cases and "definitely bad"?)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=af0fe7b8933f09dbb41227b43c7d4d831b3c162d commit af0fe7b8933f09dbb41227b43c7d4d831b3c162d Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2022-11-23 09:23:02 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2022-11-23 09:24:12 +0000 x11-libs/motif: Fix some function declarations Closes: https://bugs.gentoo.org/864533 Closes: https://bugs.gentoo.org/870799 Signed-off-by: Ulrich Müller <ulm@gentoo.org> x11-libs/motif/Manifest | 1 + x11-libs/motif/motif-2.3.8-r4.ebuild | 112 +++++++++++++++++++++++++++++++++++ 2 files changed, 113 insertions(+)
