Bug 692078 – 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

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Mike Lothian 2019-08-13 16:05:12 UTC]

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?

[Comment 1 Mike Lothian 2019-08-13 16:06:23 UTC]

Compiling qtgui then qtwayland sorted things for me

[Comment 2 Alex Xu (Hello71) 2021-11-22 15:46:54 UTC]

this is a fundamental issue with system-wide gcc lto. when you upgrade gcc, you need to rebuild all of your static libraries.

[Comment 3 Mike Lothian 2021-11-22 16:57:57 UTC]

Would an emerge -evD world not cover that?

[Comment 4 Larry the Git Cow 2023-12-12 13:04:20 UTC]

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 <[e-mail]>
AuthorDate: 2023-12-07 17:56:50 +0000
Commit:     Andreas Sturmlechner <[e-mail]>
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 <[e-mail]>

 eclass/qt5-build.eclass | 3 +++
 1 file changed, 3 insertions(+)

[Comment 5 Mike Lothian 2023-12-12 13:13:36 UTC]

How do I disable this locally?

I've been using LTO successfully for years and I still wish to use it

[Comment 6 CaptainBlood 2023-12-12 21:39:24 UTC]

(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.

[Comment 7 Sam James 2023-12-12 23:59:02 UTC]

(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.

[Comment 8 Sam James 2023-12-12 23:59:15 UTC]

(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.

[Comment 9 Mike Lothian 2023-12-17 16:54:32 UTC]

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

[Comment 10 Sam James 2023-12-17 16:56:09 UTC]

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.

[Comment 11 Mike Lothian 2023-12-17 17:02:25 UTC]

What about something like: 

    if [[ -z ${I_PROMISE_TO_SUPPLY_PATCHES_WITH_BUGS} ]] ; then
        filter-lto
    fi

Either with LTO/QT5 in there too?