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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
