On 9/30/20 7:39 AM, Robert-André Mauchin wrote:
On Tuesday, 18 August 2020 17:12:02 CEST Jeff Law wrote:
> So we're at a point where the F33 FTBFS issues related to LTO that I'm aware
> of
have been resolved (by opting the package out of LTO). I still expect
> some LTO issues will pop up as packages fix things like missing
> dependencies, cmake macros, etc. I continue to be available to investigate
> potential LTO issues, but package maintainers will need to contact me as
> I'm not actively looking for new LTO issues.
>
> My focus is now turning to the packages with LTO opt-outs. I'll be
> extracting
bug reports for upstream (primarily GCC), trying simple
> workarounds for old style symbol versioning, identifying backports from
> upstream GCC that allow us to remove LTO opt-outs and the like. So there
> should be a trickle of opt-outs removed, but otherwise should largely be
> invisible to the F33 release process.
> I'd like to thank everyone involved for being patient while we worked
> through
various issues and I look forward to continuing to make
> incremental improvements now that the bulk of the LTO work has landed.
>
> jeff
>
I have an issue with both Clementine and Strawberry (a fork of Clementine)
in F33 and above, users reported that disabling LTO fixes the problem.
The package builds but segfaults with:
Thread 1 "clementine" received signal SIGSEGV, Segmentation fault.
0x00007ffff77f7e5b in void doActivate<false>(QObject*, int, void**) () from
/lib64/libQt5Core.so.5
(gdb) bt
#0 0x00007ffff77f7e5b in void doActivate<false>(QObject*, int, void**) () at
/lib64/libQt5Core
[ ... ]
The backtrace doesn't contain the value of the arguments, but there's a
very very good chance this is the same issue that I'm working on with
kstars and twinkle. We're getting multiple definitions of an object
that's supposed to be a singleton. If you've got a gdb session active,
the following would give me enough to conclude it's the same issue.
x/i $pc // Disassemble the current instruction
i r // Dump register state
--
I'd suggest disabling LTO while we sort that issue out via
%define _lto_cflags %{nil}
In the .spec file. That form of opt-out is flagged by my .spec file
scanner and once we fix the issue I can easily go back, retest and turn
LTO back on for those packages.
Jeff