<=1.1.0: LTO type mismatch #1056

Kangie · 2024-08-17T07:37:49Z

Upfront Information

Please provide the following information by running the command and providing
the output.

1.1.0 on Gentoo Linux

Expected Behaviour

CFLAGS="-flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing"
./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --datarootdir=/usr/share --disable-dependency-tracking --disable-silent-rules --docdir=/usr/share/doc/fvwm3-1.1.0-r1 --htmldir=/usr/share/doc/fvwm3-1.1.0-r1/html --libdir=/usr/lib64 --with-imagepath=/usr/include/X11/bitmaps:/usr/include/X11/pixmaps:/usr/share/icons/fvwm --enable-package-subdirs --disable-bidi --enable-golang --enable-nls --enable-iconv --disable-perllib --with-readline-library --enable-rsvg --enable-png --disable-mandoc --disable-htmldoc --without-termcap-library
make -j
.  .  .

Actual Behaviour

../libs/Colorset.h:86:20: error: type of ‘Colorset’ does not match original declaration [-Werror=lto-type-mismatch]
   86 | extern colorset_t *Colorset;
      |                    ^
../libs/Colorset.c:36:13: note: ‘Colorset’ was previously declared here
   36 | colorset_t *Colorset = NULL;
      |             ^
../libs/Colorset.c:36:13: note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used
lto1: some warnings being treated as errors
lto-wrapper: fatal error: x86_64-pc-linux-gnu-gcc returned 1 exit status
compilation terminated.
/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: error: lto-wrapper failed

Steps to Reproduce

Build with the CFLAGS above.

This is fixed in the meson build PR: 5215ec2

- Gentoo Linux GCC and Clang (via gentoo/stage3:nomultilib) - GCC LTO (via fvwmorg/fvwm3-build) While the issue with LTO builds has been resolved in this PR, it was incidental and we should introduce a CI pipeline that will catch LTO errors before they make it into a release. Closes: fvwmorg#1056 Signed-off-by: Matt Jolly <[email protected]>

ThomasAdam · 2024-08-21T18:36:15Z

I'm very much aware of this, but the work we're doing with Meson should help.

That being said, seeing as we'll be supporting both meson and autotools side-by-side, is there anything we need to consider here for autotools?

Kangie · 2024-08-21T21:01:30Z

AFAIK, no; there's no build system changes for LTO - that's all in compiler / CFLAGS territory.

All we really need is one (or more) CI runs that attempt LTO with the warning flags to pick up any other occurrences ( I don't believe that there are any, this should just prevent it happening again in the future).

- Gentoo Linux GCC and Clang (via gentoo/stage3:nomultilib) - GCC LTO (via fvwmorg/fvwm3-build) While the issue with LTO builds has been resolved in this PR, it was incidental and we should introduce a CI pipeline that will catch LTO errors before they make it into a release. Closes: fvwmorg#1056 Signed-off-by: Matt Jolly <[email protected]>

While the issue with LTO builds has been resolved in this PR, it was incidental and we should introduce a CI pipeline that will catch LTO errors before they make it into a release. Closes: fvwmorg#1056 Signed-off-by: Matt Jolly <[email protected]>

We now include a Meson build that uses Clang + lld as the build system to catch bugs and warningsthat our traditional autotools + GCC builds might miss. This commit changes the autotools build to be more like the meson build path: We no longer build a docker image, rather directly executing the fvwm3-build container as a github action. Factor out the GH Actions steps into a common set, and use them as a matrix set to apply to Ubuntu (glibc) and Alpine (musl). The Go version in fvwm3-build has been updated to enable use with meson and eliminate the need for a complex envvar setup and invocation, however older golang is still supported (>=1.14); we're just relying on users to tell us if something is broken. While the issue with LTO builds has been resolved in this PR, it was incidental and the introduced changes will catch LTO errors before they make it into a release. Closes: fvwmorg#1056 Co-authored-by: Thomas Adam <[email protected]> Signed-off-by: Matt Jolly <[email protected]>

While the issue with LTO builds has been resolved in this PR, it was incidental and we should introduce a CI pipeline that will catch LTO errors before they make it into a release. Closes: fvwmorg#1056 Signed-off-by: Matt Jolly <[email protected]>

We now include a Meson build that uses Clang + lld as the build system to catch bugs and warningsthat our traditional autotools + GCC builds might miss. This commit changes the autotools build to be more like the meson build path: We no longer build a docker image, rather directly executing the fvwm3-build container as a github action. Factor out the GH Actions steps into a common set, and use them as a matrix set to apply to Ubuntu (glibc) and Alpine (musl). The Go version in fvwm3-build has been updated to enable use with meson and eliminate the need for a complex envvar setup and invocation, however older golang is still supported (>=1.14); we're just relying on users to tell us if something is broken. While the issue with LTO builds has been resolved in this PR, it was incidental and the introduced changes will catch LTO errors before they make it into a release. Closes: fvwmorg#1056 Co-authored-by: Thomas Adam <[email protected]> Signed-off-by: Matt Jolly <[email protected]>

We now include a Meson build that uses Clang + lld as the build system to catch bugs and warnings that our traditional autotools + GCC builds might miss. We no longer build a docker image, instead we directly execute the fvwm3-build container as a GitHub Action. GH Actions have been factored out into a common set, and are used as a matrix set to apply to Ubuntu (glibc) and Alpine (musl). The Go version in fvwm3-build has been updated to enable use with meson and eliminate the need for a complex envvar setup and invocation, however older golang is still supported (>=1.14); we're just relying on users to tell us if something is broken. While the issue with LTO builds has been resolved in this PR, it was incidental and the introduced changes will catch LTO errors before they make it into a release. Closes: fvwmorg#1056 Co-authored-by: Thomas Adam <[email protected]> Signed-off-by: Matt Jolly <[email protected]>

The intent of this commit is to provide a working meson build that implementation that is as close to the existing autotools build as is reasonable. Autotools should be considered deprecated; followup commits that modernise the codebase (e.g `time.h` vs `sys/time.h`) may include changes to autotools, and bugs will be fixed, however no enhancements to the autotools build will be made. Porting notes: FwvmPrompt: We use a script that calls 'find' to generate a list of sources to feed to golang in a custom target as there is not currently direct support for golang in Meson. bin/: Configured scripts are manually set to 'rwxr-xr-x'. drop -Wno-implicit-int: Modern compilers complain about this for a reason; we should not mask this. I can't find any current occurrances in the codebase and this will catch any future instances before they are merged. po: - Set GETTEXT_PACKAGE (mandatory for i18n module) - Add POTFILES to define files which need to be scanned for strings to translate See: - https://mesonbuild.com/Localisation.html - https://mesonbuild.com/i18n-module.html#i18n-module PRIVATE_COLORSET: always assume this is true For years, we've been setting FVWM_COLORSET_PRIVATE=1, so there is no need for the include guards. ci: We now include a Meson build that uses Clang + lld as the build system to catch bugs and warnings that our traditional autotools + GCC builds might miss. We no longer build a docker image, instead we directly execute the fvwm3-build container as a GitHub Action. GH Actions have been factored out into a common set, and are used as a matrix set to apply to Ubuntu (glibc) and Alpine (musl). The Go version in fvwm3-build has been updated to enable use with meson and eliminate the need for a complex envvar setup and invocation, however older golang is still supported (>=1.14); we're just relying on users to tell us if something is broken. While the issue with LTO builds has been resolved in this PR, it was incidental and the introduced changes will catch LTO errors before they make it into a release. Closes: fvwmorg#1056 Co-authored-by: Thomas Adam <[email protected]> Signed-off-by: Matt Jolly <[email protected]>

Kangie added the type:bug Something's broken! label Aug 17, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

<=1.1.0: LTO type mismatch #1056

<=1.1.0: LTO type mismatch #1056

Kangie commented Aug 17, 2024 •

edited

Loading

ThomasAdam commented Aug 21, 2024

Kangie commented Aug 21, 2024

<=1.1.0: LTO type mismatch #1056

<=1.1.0: LTO type mismatch #1056

Comments

Kangie commented Aug 17, 2024 • edited Loading

Upfront Information

Expected Behaviour

Actual Behaviour

Steps to Reproduce

See Also:

ThomasAdam commented Aug 21, 2024

Kangie commented Aug 21, 2024

Kangie commented Aug 17, 2024 •

edited

Loading