[09:05] <lubot> [telegram] <RikMills> @mitya57 if qt6-base need lto disabling, would you say the rest of the stack does as well?
[09:06] <lubot> [telegram] <RikMills> Or do we need to work through the stack one by one?
[09:38] <lubot> [telegram] <mitya57> I don't know. In Qt 5 times build flags from qtbase applied everywhere, but Qt 6 has a different build system so this may have changed.
[09:43] <lubot> [telegram] <RikMills> Trying qt base anyway, then will see what happens I guess. I note most of qt5 seems to be in the lto-disabled-list package
[09:45] <lubot> [telegram] <mitya57> Ah, that will explain it.
[09:45] <lubot> [telegram] <mitya57> Adding to that list would be much better than patching everything.
[09:46] <lubot> [telegram] <RikMills> Indeed
[10:57] <lubot> [telegram] <RikMills> qt6-base build with LTO off, but then fails on ppc64el on symbols
[10:57] <lubot> [telegram] <RikMills> sigh....
[10:58] <lubot> [telegram] <mitya57> I can mark those symbols as optional in Debian.
[11:00] <lubot> [telegram] <RikMills> That would be good. I'll retry builds in a clean PPA 1st, as armhf in the current one actually built with LTO, so I want to start there from scratch (re @mitya57: I can mark those symbols as optional in Debian.)
[11:00] <lubot> [telegram] <RikMills> Then I guess I can follow this: https://www.processon.com/view/link/61f50f161efad479c0785a08
[11:02] <lubot> [telegram] <RikMills> @mitya57 tempting to just shove all of Qt is the lto-disable-list and be done with it, but I guess it should all be checked propperly?
[11:04] <lubot> [telegram] <mitya57> If Qt 5 was there, then it makes sense.
[11:07] <lubot> [telegram] <RikMills> Ok, I will compromise then. Build qt6-base, then try the next tier in the Qt6 stack. If most of that also fails with LTO, then I'll stop and propose the whole stack goes into the lto-disabled-list. Reasonable? (re @mitya57: If Qt 5 was there, then it makes sense.)
[11:08] <lubot> [telegram] <mitya57> https://matterbridge.lubuntu.me/e0896d46/file_3938_tgs.webp
[11:08] <lubot> [telegram] <RikMills> Nice sticker!
[15:54] <lubot> [telegram] <RikMills> so far only qt6-qtbase seems to have an LTO issue
[15:54] <lubot> [telegram] <RikMills> symbols are an issue though
[15:58] <lubot> [telegram] <RikMills> wondering if some of those are LTO related
[16:01] <fvogt> How do you enable LTO? If you just pass -flto, that won't work
[16:02] <fvogt> You'd need to use DCMAKE_INTERPROCEDURAL_OPTIMIZATION:BOOL=ON and let Qt/CMake handle it itself
[16:02] <fvogt> Then it disables LTO on the version tagging object.
[16:06] <RikMills> fvogt: LTO is turned on via a patched dpkg in Ubuntu
[16:06] <fvogt> I suspected something like that
[16:07] <RikMills> https://launchpad.net/ubuntu/+source/dpkg/1.20.7.1ubuntu2
[16:08] <RikMills> https://launchpad.net/ubuntu/+source/dpkg/1.20.7.1ubuntu4
[16:08] <fvogt> You'll have to opt out of that and go the cmake way
[16:09] <RikMills> if I end up adding the qt6 packages to the excluded list it will never get enabled
[16:38] <lubot> [telegram] <RikMills> yes, disabling LTO seems to make most symbols issues go away. probably some slight delta to go to debian for ppc64el symbols
[16:40] <fvogt> You don't have to disable LTO, just disable the dpkg injection of -flto and set CMAKE_INTERPROCEDURAL_OPTIMIZATION instead
[16:41] <RikMills> not going to carry such a delta to debian. adding all qt6 to the lto-disabled list until debian enabled LTO by default seems the best thing here
[17:17] <lubot> [telegram] <RikMills> https://launchpad.net/bugs/1961324