Summary: | net-libs/webkit-gtk-2.40.5-r410[jumbo-build]: failed (compile phase): undefined reference to 'WebCore::FrameDestructionObserver::frame() const' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Joonas Niilola <juippis> |
Component: | Current packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | leio, mgorny |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 914901 | ||
Attachments: |
build.log.xz
emerge --info (amd64) net-libs:webkit-gtk-2.40.5-r410:20231014-082808.log.xz (amd64) |
Description
Joonas Niilola
![]() Created attachment 872147 [details]
build.log.xz
Note I can compile this version on stable amd64. It always fails to this exact same place, so doubt it's MAKEOPTS related (and with -jumbo-build, memory shouldn't be an issue on x86 either). Are you sure this is a valid dependency of Bug 914901? I do not believe Cinnamon has any dependencies on webkit-gtk - I don't even have it installed. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0e87dd5172bc97a6a7e18118e82aad3bbf737aa1 commit 0e87dd5172bc97a6a7e18118e82aad3bbf737aa1 Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2023-10-13 07:41:03 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2023-10-13 07:41:03 +0000 profiles/arch/x86: mask few cinnamon things pulling webkit-gtk on x86 Closes: https://bugs.gentoo.org/915197 Signed-off-by: Joonas Niilola <juippis@gentoo.org> profiles/arch/x86/package.use.mask | 6 ++++++ 1 file changed, 6 insertions(+) Reopening, the problem is still in this webkit-gtk. Created attachment 872924 [details]
emerge --info (amd64)
I can reproduce it on amd64 as well. Happens roughly after 30 hours of building it.
Created attachment 872925 [details]
net-libs:webkit-gtk-2.40.5-r410:20231014-082808.log.xz (amd64)
FWICS, the log's roughly the same but attaching for completeness.
Please do try 2.42.1 if you can. We need to stabilize that one ASAP for security and I don't have any success stories yet about it on an otherwise stable system I'm pretty sure the issue comes from building with USE=-jumbo-build, not the architecture then. With USE=jumbo-build, a bunch of source files are combined together and it's prone to end up having some source *.cpp file be happy and not fail to compile due to a missing header, because another *.cpp file included in the jumbo file (essentially e.g. `cat 1.cpp 2.cpp 3.cpp > jumbo.cpp`) includes the necessary header. There's a bunch of changes in this area in 2.42, so I suspect it might work better in this regard, but can't be sure it doesn't hit some other issue with -jumbo-build. I'll run some USE=-jumbo-build compile tests and report back. Unfortunately I don't even get that far here due to actual different arch issues, albeit this is only with disabled jumbo-build as well: /tmp/portage/net-libs/webkit-gtk-2.40.5-r410/work/webkitgtk-2.40.5/Source/JavaScriptCore/disassembler/ARM64/A64DOpcode.h:218:13: error: use of undeclared identifier 'dataLogLn' 2.42.1 USE=-jumbo-build also fails, so probably don't waste 30 hours on that quite yet, unless you can USE=jumbo-build it; this looks more common code: /tmp/portage/net-libs/webkit-gtk-2.42.1-r410/work/webkitgtk-2.42.1/Source/JavaScriptCore/b3/air/AirOptimizePairedLoadStore.cpp:129:37: error: incomplete type 'JSC::CCallHelpers' named in nested name specifier 129 | if ((argBase == Tmp(CCallHelpers::stackPointerRegister) || argBase == Tmp(GPRInfo::callFrameRegister)) && (inst.args[1].base() == Tmp(CCallHelpers::stackPointerRegister) || inst.args[1].base() == Tmp(GPRInfo::callFrameRegister))) { | ^~~~~~~~~~~~~~ /tmp/portage/net-libs/webkit-gtk-2.42.1-r410/work/webkitgtk-2.42.1/Source/JavaScriptCore/b3/air/AirInst.h:37:7: note: forward declaration of 'JSC::CCallHelpers' 37 | class CCallHelpers; | ^ /tmp/portage/net-libs/webkit-gtk-2.42.1-r410/work/webkitgtk-2.42.1/Source/JavaScriptCore/b3/air/AirOptimizePairedLoadStore.cpp:129:151: error: incomplete type 'JSC::CCallHelpers' named in nested name specifier 129 | if ((argBase == Tmp(CCallHelpers::stackPointerRegister) || argBase == Tmp(GPRInfo::callFrameRegister)) && (inst.args[1].base() == Tmp(CCallHelpers::stackPointerRegister) || inst.args[1].base() == Tmp(GPRInfo::callFrameRegister))) { | ^~~~~~~~~~~~~~ /tmp/portage/net-libs/webkit-gtk-2.42.1-r410/work/webkitgtk-2.42.1/Source/JavaScriptCore/b3/air/AirInst.h:37:7: note: forward declaration of 'JSC::CCallHelpers' 37 | class CCallHelpers; | ^ /tmp/portage/net-libs/webkit-gtk-2.42.1-r410/work/webkitgtk-2.42.1/Source/JavaScriptCore/b3/air/AirOptimizePairedLoadStore.cpp:131:52: error: incomplete type 'JSC::CCallHelpers' named in nested name specifier 131 | if (inst.args[1].base() == Tmp(CCallHelpers::stackPointerRegister)) | ^~~~~~~~~~~~~~ /tmp/portage/net-libs/webkit-gtk-2.42.1-r410/work/webkitgtk-2.42.1/Source/JavaScriptCore/b3/air/AirInst.h:37:7: note: forward declaration of 'JSC::CCallHelpers' 37 | class CCallHelpers; | ^ /tmp/portage/net-libs/webkit-gtk-2.42.1-r410/work/webkitgtk-2.42.1/Source/JavaScriptCore/b3/air/AirOptimizePairedLoadStore.cpp:135:40: error: incomplete type 'JSC::CCallHelpers' named in nested name specifier 135 | if (argBase == Tmp(CCallHelpers::stackPointerRegister)) | ^~~~~~~~~~~~~~ /tmp/portage/net-libs/webkit-gtk-2.42.1-r410/work/webkitgtk-2.42.1/Source/JavaScriptCore/b3/air/AirInst.h:37:7: note: forward declaration of 'JSC::CCallHelpers' 37 | class CCallHelpers; | ^ /tmp/portage/net-libs/webkit-gtk-2.42.1-r410/work/webkitgtk-2.42.1/Source/JavaScriptCore/b3/air/AirOptimizePairedLoadStore.cpp:237:42: error: incomplete type 'JSC::CCallHelpers' named in nested name specifier 237 | if (target.args[1].base() == Tmp(CCallHelpers::stackPointerRegister)) { | ^~~~~~~~~~~~~~ /tmp/portage/net-libs/webkit-gtk-2.42.1-r410/work/webkitgtk-2.42.1/Source/JavaScriptCore/b3/air/AirInst.h:37:7: note: forward declaration of 'JSC::CCallHelpers' 37 | class CCallHelpers; | ^ /tmp/portage/net-libs/webkit-gtk-2.42.1-r410/work/webkitgtk-2.42.1/Source/JavaScriptCore/b3/air/AirOptimizePairedLoadStore.cpp:288:53: error: incomplete type 'JSC::CCallHelpers' named in nested name specifier 288 | if ((inst.args[1].base() == Tmp(CCallHelpers::stackPointerRegister) || inst.args[1].base() == Tmp(CCallHelpers::framePointerRegister)) && !inst.kind.spill) | ^~~~~~~~~~~~~~ /tmp/portage/net-libs/webkit-gtk-2.42.1-r410/work/webkitgtk-2.42.1/Source/JavaScriptCore/b3/air/AirInst.h:37:7: note: forward declaration of 'JSC::CCallHelpers' 37 | class CCallHelpers; | ^ /tmp/portage/net-libs/webkit-gtk-2.42.1-r410/work/webkitgtk-2.42.1/Source/JavaScriptCore/b3/air/AirOptimizePairedLoadStore.cpp:288:119: error: incomplete type 'JSC::CCallHelpers' named in nested name specifier 288 | if ((inst.args[1].base() == Tmp(CCallHelpers::stackPointerRegister) || inst.args[1].base() == Tmp(CCallHelpers::framePointerRegister)) && !inst.kind.spill) | ^~~~~~~~~~~~~~ /tmp/portage/net-libs/webkit-gtk-2.42.1-r410/work/webkitgtk-2.42.1/Source/JavaScriptCore/b3/air/AirInst.h:37:7: note: forward declaration of 'JSC::CCallHelpers' 37 | class CCallHelpers; | ^ 7 errors generated. (In reply to Mart Raudsepp from comment #9) > I'm pretty sure the issue comes from building with USE=-jumbo-build, not the > architecture then. > Sounds plausible as I can build this version on amd64. I have jumbo-build enabled there, disabled on x86. (In reply to Mart Raudsepp from comment #9) > I'm pretty sure the issue comes from building with USE=-jumbo-build, not the > architecture then. Is jumbo-build likely to work on 4G of RAM? 4GB is probably sketchy, not sure. I suggest you package.accept_keyword 2.42.1 specifically and go with that, we'll security stable that soon, so you'd need another 30 hours otherwise again as well. I've tried 2.42.1 here without jumbo-build, and you should hopefully be good - it only fails in ARM64 specifics with USE=-jumbo-build and the rest went well for me. I'll patch that tomorrow or so (working locally, need to formalize commits, but it's late now), but those failures and fixes are for stuff wrapped in #if ENABLE(B3_JIT) #if CPU(ARM64) .. so you should be good with 2.42.1 revisions. Can't guarantee there aren't some issues with other USE flag differences though. USE=-gstreamer has been historically fun. Here's what I'm trying: [ebuild N ~] net-libs/webkit-gtk-2.42.1-r410:4.1/0::gentoo USE="X avif (gstreamer) introspection jpeg2k jpegxl keyring lcms pdf (seccomp) spell systemd wayland (-aqua) -examples -gamepad -jumbo-build" 0 KiB See you tomorrow xP. (In reply to Michał Górny from comment #12) > > Is jumbo-build likely to work on 4G of RAM? Chromium and Firefox had/has a way to fine-tune the amount of parallel files, I wonder if webkit-gtk has something similar to that? I couldn't find anything obvious while quickly browsing the source code. My impression was that they have some cmake dark magic to automatically figure something out for that based on the environment, but it was from reading what someone else was saying, not personal research into it. At least in the past I'm pretty sure I've seen different total number of files to compile reported by ninja across different machines with the same version/revision and roughly the same USE flags. To me the main issue on lower-end machines has been the linking step, where swap tended to not even help due to some kind of linker memory access types - that's a case for per-package -Wl,--no-keep-memory in LDFLAGS to help against that a bit. In my build test I had all USE flags except example and jumbo-build, so I think it ought to go well for mgorny, unless there's any x86(_64)-specific issues. gamepad should be very low impact and not the kind of code that would be prone to missing headers. Thanks. I can confirm that 2.42.1-r410 built successfully. @juippis - want to drop the profile tweaks you did now, or keep them due to the heavy compile on x86 systems or something? If keeping, the explanation should at least be tweaked to the current reason (plus the problem was non-unified build, not x86). The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2aa9fb4a62890b875e5654141fa02e647d04ef8c commit 2aa9fb4a62890b875e5654141fa02e647d04ef8c Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2023-10-22 06:08:42 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2023-10-22 06:08:42 +0000 profiles/arch/x86: allow webkit-gtk to be pulled by cinnamon on x86 - the problem on x86-stable was webkit-gtk[-jumbo-build], which will be fixed on next webkit-gtk stable. Bug: https://bugs.gentoo.org/915197 Signed-off-by: Joonas Niilola <juippis@gentoo.org> profiles/arch/x86/package.use.mask | 6 ------ 1 file changed, 6 deletions(-) I guess all is good here then. At least for now until the next webkit-gtk series :) |