https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: dev-util/gperf-3.1 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
Created attachment 791738 [details] build.log build log and emerge --info
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
lto_tinderbox has reproduced this issue with version 3.1-r1 - Updating summary.
Not restricted to LTO - same on non-lto cd src; make all make[1]: Entering directory '/var/tmp/portage/dev-util/gperf-3.1-r1/work/gperf-3.1/src' x86_64-pc-linux-gnu-g++ -O2 -pipe -march=native -Werror=strict-aliasing -Werror=odr -Werror=lto-type-mismatch -flifetime-dse=1 -I. -I./../lib -c ./version.cc x86_64-pc-linux-gnu-g++ -O2 -pipe -march=native -Werror=strict-aliasing -Werror=odr -Werror=lto-type-mismatch -flifetime-dse=1 -I. -I./../lib -c ./positions.cc x86_64-pc-linux-gnu-g++ -O2 -pipe -march=native -Werror=strict-aliasing -Werror=odr -Werror=lto-type-mismatch -flifetime-dse=1 -I. -I./../lib -c ./options.cc x86_64-pc-linux-gnu-g++ -O2 -pipe -march=native -Werror=strict-aliasing -Werror=odr -Werror=lto-type-mismatch -flifetime-dse=1 -I. -I./../lib -c ./keyword.cc x86_64-pc-linux-gnu-g++ -O2 -pipe -march=native -Werror=strict-aliasing -Werror=odr -Werror=lto-type-mismatch -flifetime-dse=1 -I. -I./../lib -c ./keyword-list.cc In file included from ./keyword-list.h:78, from ./keyword-list.cc:22: ./keyword-list.icc: In member function ‘KeywordExt_List*& KeywordExt_List::rest()’: ./keyword-list.icc:50:11: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] 50 | return *reinterpret_cast<KeywordExt_List**>(&_cdr); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1plus: some warnings being treated as errors make[1]: *** [Makefile:107: keyword-list.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory '/var/tmp/portage/dev-util/gperf-3.1-r1/work/gperf-3.1/src' make: *** [Makefile:34: all] Error 2 * ERROR: dev-util/gperf-3.1-r1::gentoo failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=dev-util/gperf-3.1-r1::gentoo'`, * the complete build log and the output of `emerge -pqv '=dev-util/gperf-3.1-r1::gentoo'`. * The complete build log is located at '/var/log/portage/dev-util:gperf-3.1-r1:20230115-225352.log'. * For convenience, a symlink to the build log is located at '/var/tmp/portage/dev-util/gperf-3.1-r1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-util/gperf-3.1-r1/temp/environment'. * Working directory: '/var/tmp/portage/dev-util/gperf-3.1-r1/work/gperf-3.1' * S: '/var/tmp/portage/dev-util/gperf-3.1-r1/work/gperf-3.1' >>> Failed to emerge dev-util/gperf-3.1-r1, Log file:
Unfortunately I can reproduce the issue as well. I created the following nolto.conf file and added the program in question to nolto.conf but made no difference >>> CFLAGS="${CFLAGS} -fno-lto" CXXFLAGS="${CXXFLAGS} -fno-lto" FCFLAGS="${FCFLAGS} -fno-lto" FFLAGS="${FFLAGS} -fno-lto" <<< I am using the following COMMON_FLAGS in make.conf: COMMON_FLAGS="-march=alderlake -O2 -pipe -flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing" Any help to fix / bybass the error would be appreciated. Thanks
A workaround would be to make an env file which appends -fno-strict-aliasing for all the packages that fail because of that error until they are fixed upstream. https://marc.info/?l=gentoo-dev&m=165639574126280&w=2
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c552aae1e4c2dc88ad964fd4134505c2cdf0d26e commit c552aae1e4c2dc88ad964fd4134505c2cdf0d26e Author: Sam James <sam@gentoo.org> AuthorDate: 2024-01-05 13:24:08 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-05 13:24:46 +0000 dev-util/gperf: filter LTO, disable strict aliasing Closes: https://bugs.gentoo.org/858377 Signed-off-by: Sam James <sam@gentoo.org> dev-util/gperf/gperf-3.1-r2.ebuild | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+)
People are going to be confused about this being "fixed". So I feel compelled to point out that this will still fail to build with -Werror=strict-aliasing until it's addressed upstream. The LTO problems are fixed, but those who are prudently watching for LTO incompatibility will still see build failures.
(In reply to Anthony Ryan from comment #8) > People are going to be confused about this being "fixed". > > So I feel compelled to point out that this will still fail to build with > -Werror=strict-aliasing until it's addressed upstream. > > The LTO problems are fixed, but those who are prudently watching for LTO > incompatibility will still see build failures. I'm sorry, but no. Keeping every downstream bug open unless and until an upstream fix is implemented would make it way harder to see what actually needs action on our end. In particular, gperf is kind of a weird case, because even its last "release" from a few years ago never got tagged/a tarball made proeprly either. And no, it won't. Passing -fno-strict-aliasing, as I did, means that -Werror=strict-aliasing won't fire, because there is no aliasing violation in the dialect of the language being used. I am the person who started the effort for LTO incompatibility being pointed out by such flags and wrote all of the documentation for it - I'm aware of the pitfalls.
> And no, it won't. Passing -fno-strict-aliasing, as I did, means that > -Werror=strict-aliasing won't fire, because there is no aliasing violation > in the dialect of the language being used. I stand corrected. When I ran QA tests on this without our no-lto on my work testing infrastructure it all came up failing still. But it appears that's because I was testing amd64 and not ~amd64. My apologies.
*** Bug 922323 has been marked as a duplicate of this bug. ***
