Summary: | dev-qt/qtwayland-5.12.4-r1 with dev-qt/qtgui built with LTO - lto1: fatal error: bytecode stream in file ‘/usr/lib64/libQt5FontDatabaseSupport.a’ generated with LTO version 8.0 instead of the expected 8.1 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mike Lothian <mike> |
Component: | Current packages | Assignee: | Qt Bug Alias <qt> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | marc_heimann, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 618550 | ||
Attachments: | build log |
Compiling qtgui then qtwayland sorted things for me this is a fundamental issue with system-wide gcc lto. when you upgrade gcc, you need to rebuild all of your static libraries. Would an emerge -evD world not cover that? The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2d51131e1ec7aa03f22a2f2864237fdc3d4dc146 commit 2d51131e1ec7aa03f22a2f2864237fdc3d4dc146 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2023-12-07 17:56:50 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2023-12-12 12:56:01 +0000 qt5-build.eclass: filter-lto Closes: https://bugs.gentoo.org/650488 Closes: https://bugs.gentoo.org/692078 Closes: https://bugs.gentoo.org/713850 Closes: https://bugs.gentoo.org/908419 Closes: https://bugs.gentoo.org/652158 Closes: https://bugs.gentoo.org/919043 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> eclass/qt5-build.eclass | 3 +++ 1 file changed, 3 insertions(+) How do I disable this locally? I've been using LTO successfully for years and I still wish to use it (In reply to Mike Lothian from comment #5) > How do I disable this locally? > > I've been using LTO successfully for years and I still wish to use it Yeah, belt, braces (suspenders) & baby diaper isn't a strategy everyone wants to follow to prevent accident regarding pants. (In reply to CaptainBlood from comment #6) > (In reply to Mike Lothian from comment #5) > > How do I disable this locally? > > > > I've been using LTO successfully for years and I still wish to use it > > Yeah, belt, braces (suspenders) & baby diaper isn't a strategy everyone > wants to follow to prevent accident regarding pants. This isn't theoretical though - see the tagged bugs. Ultimately, the issue is nobody really cares about Qt 5 at this point. (In reply to Mike Lothian from comment #5) > How do I disable this locally? > > I've been using LTO successfully for years and I still wish to use it Use a post-sync hook to patch the eclass. Thanks, I was hoping for a better way to allow it, I'll submit a patch with a I_WANT_LTO env variable or something LTO works great, on GCC and Clang here, the only issues I had were with portage building things out or order when rebuilding things when new versions of GCC was released, I've not seen that issue for a while so I assumed (maybe incorrectly) it was fixed I don't really see the point here - there's UB (see the other bugs) and there's no upstream support or interest in 5 bugs, plus can't do Asan/ubsan. So if you really want it, against advice, patch the eclass via a post sync hook. It isn't really suitable for custom-cflags here. The qtscript bug was the straw that broke the camels back. What about something like: if [[ -z ${I_PROMISE_TO_SUPPLY_PATCHES_WITH_BUGS} ]] ; then filter-lto fi Either with LTO/QT5 in there too? |
Created attachment 586722 [details] build log I'm rebuilding my system with GCC 9.2 (emerge -evD world -j5) lto1: fatal error: bytecode stream in file ‘/usr/lib64/libQt5FontDatabaseSupport.a’ generated with LTO version 8.0 instead of the expected 8.1 compilation terminated. lto-wrapper: fatal error: x86_64-pc-linux-gnu-g++ returned 1 exit status compilation terminated. /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld.gold: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status make[2]: *** [Makefile:337: ../../lib/libQt5WaylandClient.so.5.12.4] Error 1 make[2]: Leaving directory '/var/tmp/portage/dev-qt/qtwayland-5.12.4-r1/work/qtwayland-everywhere-src-5.12.4/src/client' make[1]: *** [Makefile:76: sub-client-make_first] Error 2 make[1]: *** Waiting for unfinished jobs.... Despite qtgui being a DEPEND for qtwayland, qtwayland was built first (perhaps because it was already installed) Is this a portage bug?