Quote:
Originally Posted by KevinH
FWIW, if you search the gcc.gnu.org bugzilla for "lto" (link time optimizer -flto) you will see a large number of freshly reported lto gcc bugs this month alone and not counting the ones in April or earlier.
|
One of the Arch maintainers mentioned that same thing in the bug report.
Quote:
Originally Posted by KevinH
Not sure why they add that compiler switch for Sigil, but given it works with lto with Qt6 but not with Qt5, then it is something in Qt5 that probably triggers the gcc bug.
|
I think the switch -flto switch may just be a standard for their packaging. They don't explicitly set it for Sigil, but they always add the following to their cmake config for Sigil:
Code:
-DCMAKE_C_FLAGS:STRING="$CFLAGS" \
-DCMAKE_CXX_FLAGS:STRING="$CXXFLAGS" \
Quote:
Originally Posted by KevinH
Perhaps just dropping the lto switch from the Sigil builds and building with Qt5 might be the safest path forward for Arch. Or using clang?
|
I mentioned (in the bug report) that I'm not opposed to them moving to Qt6 for their packages. It has seemed fairly stable for a while now. I've built Sigil with clang on Linux myself, but I've not done a lot of testing. But if it seems sufficient, I'm not opposed to that either. I just don't want to increase the work that debugging issues on Sigil might entail by having packages out there built with clang, gcc, AND qt5 vs qt6.
Quote:
Originally Posted by KevinH
That said, why is Arch the only one seeing this if the bug is in the latest gcc? Perhaps other distributions actually have the same issue. Does anyone know?
|
Not sure. Perhaps not that many are using the latest version of gcc (or not many are requiring -flto be used to build packages)?
EDIT: and yes from a comment over there, it looks like it's the default to append LTOFLAGS to CXXFLAGS when package building.
https://bugs.archlinux.org/task/7487...5&string=sigil