https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: dev-libs/xerces-c-3.2.3-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
Created attachment 789857 [details] build.log.xz build log and emerge --info (compressed because it exceeds attachment limit, use 'xzless' to read it)
Error(s) that match a know pattern in addition to what has been reported in the summary: -- Could NOT find Java (missing: Java_JAVA_EXECUTABLE Runtime) /var/tmp/portage/dev-libs/xerces-c-3.2.3-r2/work/xerces-c-3.2.3/src/xercesc/dom/impl/DOMLSSerializerImpl.cpp: In member function ‘bool xercesc_3_2::DOMLSSerializerImpl::reportError(const xercesc_3_2::DOMNode*, xercesc_3_2::DOMError::ErrorSeverity, const XMLCh*)’: /var/tmp/portage/dev-libs/xerces-c-3.2.3-r2/work/xerces-c-3.2.3/src/xercesc/dom/impl/DOMLSSerializerImpl.cpp: In member function ‘bool xercesc_3_2::DOMLSSerializerImpl::reportError(const xercesc_3_2::DOMNode*, xercesc_3_2::DOMError::ErrorSeverity, xercesc_3_2::XMLDOMMsg::Codes)’: FAILED: tests/CMakeFiles/DOMTest.dir/src/DOM/DOMTest/DTest.cpp.o /var/tmp/portage/dev-libs/xerces-c-3.2.3-r2/work/xerces-c-3.2.3/tests/src/DOM/DOMTest/DTest.cpp:3013:40: error: dereferencing type-punned pointer will break strict-aliasing rules [-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
It seems to me that the issue is not related to lto option(s) as it also appears on machines not using those flags. Catching strict aliasing issues seems to be a good practice as aliasing may lead to random behavior, depending on how the compiler would optimize the code. For this particuliar case, -fstrict-aliasing is 'hardcoded' in package cmake configuration and it would be better not to use it if there are possible issues. Thus, the following patch seems to fix the problem, if any: --- xerces-c-3.2.2/cmake/XercesWarnings.cmake 2018-02-15 02:22:34.000000000 +0100 +++ xerces-c-3.2.2/cmake/XercesWarnings.cmake 2019-04-05 11:03:44.806398203 +0200 @@ -50,8 +50,7 @@ if(CMAKE_CXX_COMPILER_ID STREQUAL GNU -Wswitch-default -Wunused-variable -Wwrite-strings - -Wno-variadic-macros - -fstrict-aliasing) + -Wno-variadic-macros) if(extra-warnings) list(APPEND test_flags -Wfloat-equal
(In reply to Jocelyn Mayer from comment #4) > It seems to me that the issue is not related to lto option(s) as it also > appears on machines not using those flags. > Catching strict aliasing issues seems to be a good practice as aliasing may > lead to random behavior, depending on how the compiler would optimize the > code. Yes, it's just more likely to break with LTO. > For this particuliar case, -fstrict-aliasing is 'hardcoded' in package cmake > configuration and it would be better not to use it if there are possible > issues. > Thus, the following patch seems to fix the problem, if any: > I don't think this will help given -O2 enables it anyway.
(In reply to Sam James from comment #5) > > > For this particuliar case, -fstrict-aliasing is 'hardcoded' in package cmake > > configuration and it would be better not to use it if there are possible > > issues. > > Thus, the following patch seems to fix the problem, if any: > > > > I don't think this will help given -O2 enables it anyway. I think what Jocelyn meant was that the package's build system adds -fstrict-aliasing to the end of the flags, so even if you add -fno-strict-aliasing with package.env, the build will still use the "override" from the build system, and thus fail if -Werror=strict-aliasing is enabled.
Ah! OK, let me fix. Sorry Jocelyn, you are absolutely right, and I'd misread the patch.
It's only in tests but I'm just going to disable it anyway as they're clearly not testing it.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=231fb829f816206e368c83c44e3f3a175b217918 commit 231fb829f816206e368c83c44e3f3a175b217918 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-01-10 11:21:09 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-10 11:21:57 +0000 dev-libs/xerces-c: disable strict aliasing, filter LTO It's only in the tests but it implies they're not testing it at all. Closes: https://bugs.gentoo.org/856100 Signed-off-by: Sam James <sam@gentoo.org> .../files/xerces-c-3.2.4-strict-aliasing.patch | 13 +++ dev-libs/xerces-c/xerces-c-3.2.4-r3.ebuild | 123 +++++++++++++++++++++ dev-libs/xerces-c/xerces-c-9999.ebuild | 15 ++- 3 files changed, 147 insertions(+), 4 deletions(-)
