https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: x11-wm/fvwm3-1.0.4-r2 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 799357 [details] build.log build log and emerge --info
lto_tinderbox has reproduced this issue with version 1.0.9-r1 - Updating summary.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a7ff4695abec63c8ef91b29d533ec89c80636190 commit a7ff4695abec63c8ef91b29d533ec89c80636190 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-08-15 19:04:41 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-08-15 19:07:03 +0000 x11-wm/fvwm: fix patches * Use rebased ar, translucent-menus patches from bug #898918, thanks to Gianni Ceccarelli <dakkar@thenautilus.net> * Filter LTO for bug #864957 (fvwm 2.x is EOL) so unlikely to be fixed upstream. If 3.x gets fixed (bug #864959), we can always look at backporting it. Bug: https://bugs.gentoo.org/864959 Closes: https://bugs.gentoo.org/864957 Closes: https://bugs.gentoo.org/898918 Signed-off-by: Sam James <sam@gentoo.org> x11-wm/fvwm/files/fvwm-2.7.0-ar.patch | 41 ++ .../fvwm/files/fvwm-2.7.0-translucent-menus.diff | 507 +++++++++++++++++++++ x11-wm/fvwm/fvwm-2.7.0-r5.ebuild | 172 +++++++ 3 files changed, 720 insertions(+)
I can't reproduce this with a 1.10-git meson build path. I _think_ it's resolved upstream but have no idea which change fixed it.
The log doesn't show it (I've filed GCC bugs before for that to be improved) but the issue is https://github.com/fvwmorg/fvwm3/blob/d26bed64c827d124b053e978f380c6b487f056eb/libs/Colorset.h#L35. i.e. sometimes the define is set, sometimes not.
Yeah, just managed to repro with the 1.10 tarball. Whee!
Fixed upstream in the Meson PR by coincidence: https://github.com/fvwmorg/fvwm3/pull/996/commits/5215ec25918255e5e708420caacc1b6fa98d74f2 I'll close this off once we get that merged and redo the ebuild. If we're lucky I'll backport to fvwm2 :)
*** Bug 945074 has been marked as a duplicate of this bug. ***
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=18709c58925b29ec455d2841efa66ab8ff747ac0 commit 18709c58925b29ec455d2841efa66ab8ff747ac0 Author: Matt Jolly <kangie@gentoo.org> AuthorDate: 2024-12-01 03:12:27 +0000 Commit: Matt Jolly <kangie@gentoo.org> CommitDate: 2024-12-01 03:18:23 +0000 x11-wm/fvwm3: drop 1.0.9-r1, 1.1.0-r1 The major fixes that came with 1.1.1/meson, and the canary users who have been testing on live have made me comfortable dropping the older packages immediately. Closes: https://bugs.gentoo.org/864959 Closes: https://bugs.gentoo.org/939531 Closes: https://bugs.gentoo.org/919163 Signed-off-by: Matt Jolly <kangie@gentoo.org> x11-wm/fvwm3/Manifest | 4 - .../files/fvwm3-1.1.0-fix-go-detection-v2.patch | 50 ----- x11-wm/fvwm3/fvwm3-1.0.9-r1.ebuild | 202 -------------------- x11-wm/fvwm3/fvwm3-1.1.0-r1.ebuild | 203 --------------------- 4 files changed, 459 deletions(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2e5fd6875a959b56b5f82568a06ab1cd1f31fa14 commit 2e5fd6875a959b56b5f82568a06ab1cd1f31fa14 Author: Matt Jolly <kangie@gentoo.org> AuthorDate: 2024-12-01 02:23:40 +0000 Commit: Matt Jolly <kangie@gentoo.org> CommitDate: 2024-12-01 03:18:15 +0000 x11-wm/fvwm3: add 1.1.1, sync live This update brings the meson build sytem among other improvements! Bug: https://bugs.gentoo.org/864959 Bug: https://bugs.gentoo.org/939531 Bug: https://bugs.gentoo.org/919163 Closes: https://bugs.gentoo.org/944780 Signed-off-by: Matt Jolly <kangie@gentoo.org> x11-wm/fvwm3/Manifest | 2 + x11-wm/fvwm3/files/fvwm3-1.1.1-desk-init.patch | 32 +++++ x11-wm/fvwm3/fvwm3-1.1.1.ebuild | 185 +++++++++++++++++++++++++ x11-wm/fvwm3/fvwm3-9999.ebuild | 47 ++++--- x11-wm/fvwm3/metadata.xml | 3 - 5 files changed, 246 insertions(+), 23 deletions(-)
