Created attachment 914891 [details] emerge --info net-libs/webkitgtk Upstream supports O3+LTO builds but lto was disabled in the ebuild in commit gitweb.gentoo.org/repo/gentoo.git/commit/?id=21109fa861f07a6ae06cfbed1ef2c721bfae9afd (new accounts aren't allowed to post links) I haven't ran into these odr errors and I have been using lto with both gcc and with recently with 2.46 version clang. Have been daily driving Epiphany for a couple months with this setup.
See the 2.44.4 release notes webkitgtk.org/release/webkitgtk-2.44.4.html Which fixed a bug with clang lto builds
The upstream bug at https://bugs.webkit.org/show_bug.cgi?id=233007 remains open -- is the ODR issue actually fixed?
https://github.com/WebKit/WebKit/blob/main/Source/cmake/WebKitCompilerFlags.cmake#L210 further doesn't inspire confidence. I don't think it's actually fixed.
(In reply to Sam James from comment #2) > The upstream bug at bugs.webkit.org/show_bug.cgi?id=233007 remains > open -- is the ODR issue actually fixed? Its not. I had a conversation with WebKit developers on matrix in #epiphany:gnome.org room about WebKitGTK's performance and I brought up how in gentoo LTO was disabled and heres what they said to me: > We don't try every GCC/Clang version out there that distros may be using > That would be too much > If you run into issues after enabling LTO, we would be more than happy to get bug reports > It's not officially stated anywhere, but the intention is to support LTO builds
It's good to open with that if it already happened when you opened the bug. Anyway, I still don't like it, but I suppose we could give webkit-gtk the same exception we gave Firefox ("performance matters a lot for browsers, it's probably fine, the ODR violations which are known to be unfixed aren't in a particularly scary component (bundled libraries and so on instead, not rendering or whatever)"). We'll see what gnome@ says.
(In reply to Sam James from comment #5) > It's good to open with that if it already happened when you opened the bug. Haha yes will do that next time I just don't have a way to export matrix chat > > Anyway, I still don't like it, but I suppose we could give webkit-gtk the > same exception we gave Firefox ("performance matters a lot for browsers If anyone needs any convincing WebKitGTK gets about ~12-15% performance boost with LTO and another ~5% percent with -O3
(In reply to wxviolation from comment #6) > (In reply to Sam James from comment #5) > If anyone needs any convincing WebKitGTK gets about ~12-15% performance boost > with LTO and another ~5% percent with -O3 With clang on WebKitGTK 2.46 FYI, nobodys benchmarked with gcc yet
I don't have enough RAM to test it, but if upstream says it's OK, I guess it's OK.
Well, -Wodr errors are still here https://bugs.gentoo.org/947279#c1 Upstream says they're fine but downstream -Werror would need to filtered out
(In reply to wxviolation from comment #9) > Upstream says they're fine but downstream -Werror would need to filtered out I'd strongly prefer to not do that.
(In reply to wxviolation from comment #9) > Upstream says they're fine but downstream -Werror would need to filtered out Oops sorry I meant -Werror=odr, if thats even possible to do in ebuilds
Created attachment 919109 [details] net-libs/webkit-gtk: 2.46.6 version bump Heres an udpate with lto enabled and -Werror=odr filtered out
(In reply to zyxhere from comment #12) > Created attachment 919109 [details] > net-libs/webkit-gtk: 2.46.6 version bump > > Heres an udpate with lto enabled and -Werror=odr filtered out I still don't think we want to do this. The ODR violation should be fixed if we want to allow LTO.
(In reply to Sam James from comment #13) > (In reply to zyxhere from comment #12) > > Created attachment 919109 [details] > > net-libs/webkit-gtk: 2.46.6 version bump > > > > Heres an udpate with lto enabled and -Werror=odr filtered out > > I still don't think we want to do this. The ODR violation should be fixed if > we want to allow LTO. Even though upstream supports LTO? (P.S the keywords are messed up in my patch)
Feel like we're going circles on this. I expressed a willingness to possibly make an exception in https://bugs.gentoo.org/946940#c5 but I'd still really prefer not to. Not having -Wodr means we don't know about real problems when they arise and we're then stuck trying to debug it. If you really care about having LTO on it, why not fix the actual problem? You need to use flex/bison's prefix/remapping support.
Of course the real solution is to fix the odr bugs I would if I could but I only know a tiny amount of rust and shell. I would say to enable back LTO, WebKits has a reputation for being slow already so it really needs any extra performance it can get.
I have been reviewing a bit what other distributions are doing: - I couldn't find real fixes on the underlying issue :S - Debian and openmandriva are disabling LTO. - Fedora and OpenSuSE are enabling it but excluding ppc64lte and x86. - Alpine passes -DLTO_MODE=thin https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/webkit2gtk-6.0/APKBUILD#L122 - Chimera also use -DLTO_MODE=thin, but it seems that they disable it for arm64 due to some breakage with JIT: https://github.com/chimera-linux/cports/blob/master/main/webkitgtk/template.py#L127
I think the fact that LTO has reported led to it crashing on arm64 and presumably Fedora/SUSE discovered similar problems that led to them disabling it on multiple other platforms, is pretty worrying and indicates that it isn't safe to enable LTO here -- even the Firefox exception "performance matters a lot for browsers, it's probably fine" is predicated on Firefox successfully running when you do so.
