Bug 723372 and Bug 703862 indicated that PPC64 (and big endian support in general) is broken on www-client/seamonkey. This is mainly due to upstream not having the resources to work on and test this. With the bug I want to track and discuss what would be needed to restore PPC64 support for www-client/seamonkey on Gentoo Linux. Reproducible: Always
Current status is that the chromium part has build problems, suggested patch is here: https://github.com/zeldin/chromium_be/blob/master/chromium-89.0.4389.114/sandbox.patch
>This is mainly due to upstream not having the resources to work on and test this. Also because upstream keeps vendoring chromium components, despite known anti-portability stance of chromium team. :-/ I'm not sure how much of the portability issues with skia has already been fixed by the mozilla team, but additional fragments of https://github.com/zeldin/chromium_be/blob/master/chromium-89.0.4389.114/skia.patch may also be required to fix issues like incorrect colours and disappearing text, which I have observed on unpatched chromium.
(In reply to Marcus Comstedt from comment #2) > >This is mainly due to upstream not having the resources to work on and test this. > > Also because upstream keeps vendoring chromium components, despite known > anti-portability stance of chromium team. :-/ Seamonkey isn't maintained by Mozilla any more. Mozilla took their hand off from it some time ago. A new foundation has been created for Seamonkey and most work these days involves backporting Mozilla patches. So that's the difficulty to work with. So, Seamonkey upstream prefers to backport patches as much as possible, but I think your patches could come in handy too: 1) Fix things in Gentoo first. This can be done independent from Seamonkey upstream. and later, 2) Point Seamonkey upstream to which Mozilla patches are required to fix things upstream. Which is something more for me and beyond this bug report. Even then, if there are no Mozilla patches I think I can move Seamonkey upstream to include additional fixes.
@Myckel Thanks for the clarification. I'll start taking a look at the www-client/seamonkey-2.53.11.1 ebuild, and if I find things which need patches, I'll add them to my /etc/portage/patches and post them here as well. Then we can take it from there.
Great! Even if you have things that seem to progress the build a little further, share them here.
Created attachment 768146 [details, diff] Patch to fix "--disable-elf-hack is not available in this configuration" build error
Created attachment 768147 [details, diff] Patch to disable SSE stuff in webrtc on non-x86 (see also bug 758308)
Created attachment 768148 [details, diff] Patch to fix chromium sandbox build errors on ppc64
Ok, here's three patches to start with. elfhack.patch: This patches the config scripts so that they accept "--disable-elf-hack" even on arches which do not have elf-hack. A better fix would probably be to modify the ebuild so that it only passes "--disable-elf-hack" on arches where it is needed. webrtc.patch: A fix for bug 758308. It looks like someone "fixed" it by making the assumption that everything except aarch64 has intel-specific ISA. Newsflash: Not actually the case... sandbox.patch: This is just the chromium sandbox patch rebased on the version of sandbox used in seamonkey. Plus a minor change to use the string "ppc64" as SANDBOX_ARCH_NAME on ppc64, in code not derived from chromium sources. Now the build fails in pixman: 8 0:03.48 /tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/gfx/cairo/libpixman/src/pixman-vmx.c:28:10: fatal error: config.h: No such file or directory 8 0:03.48 28 | #include <config.h> 8 0:03.48 | ^~~~~~~~~~ 8 0:03.48 compilation terminated. Not sure if this is one I've seen before...
Hm, isn't it strange that it's trying to build its own pixman in the first place? I mean the ebuild does have a dep on the system pixman: >=x11-libs/pixman-0.19.2
Ok, with EXTRA_ECONF="--enable-system-pixman" I get past that. Now it seems there is some more sandbox woes: 0:09.15 /tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/toolkit/xre/nsEmbedFunctions.cpp: In function 'nsresult XRE_InitChildProcess(int, char**, const XREChildData*)': 0:09.15 /tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/toolkit/xre/nsEmbedFunctions.cpp:351:14: error: 'SandboxEarlyInit' is not a member of 'mozilla' 0:09.15 351 | mozilla::SandboxEarlyInit(XRE_GetProcessType()); 0:09.15 | ^~~~~~~~~~~~~~~~ The quest continues...
Created attachment 768152 [details, diff] Patch to fix incorrect include guard in nsEmbedFunctions.cpp
Created attachment 768153 [details, diff] Patch to add missing global mutex
Ok, two more patches, and now it builds (still requiring EXTRA_ECONF="--enable-system-pixman"). xre-sandbox.patch: There seems to different tiers of sandboxing - on x86 MOZ_GMP_SANDBOX is defined, but on ppc64 only the base MOZ_SANDBOX is defined. nsEmbedFunctions.cpp has code inside #ifdef MOZ_SANDBOX which needs Sandbox.h to be included, but said include of Sandbox.h is guarded by #ifdef MOZ_GMP_SANDBOX. (MOZ_SANDBOX is implied by MOZ_GMP_SANDBOX, but not the other way around.) So this is a plain bug. ipc.patch: After fixing the webrtc build to use generic code instead of SSE, it seems a reference to a global mutex has appeared. ipc/chromium/moz.build has a long list of arches where _not_ to generate this global mutex, and ppc64 is on it. Removing ppc64 from the list makes the mutex appear and the application links. Running still doesn't work, there is a segfault really early - a null pointer dereference in what looks like generated code. So potentially some JIT with broken support for ELF v1.
Hm, no it looks like the segfault was actually intentional, and triggered by MOZ_RELEASE_ASSERT(mNode) in memory/build.h/rb.h, somewhere deep inside jemalloc. By adding "--disable-jemalloc" to EXTRA_ECONF I get a little further; now it's instead crashing here: #ifdef JS_CODEGEN_NONE MOZ_CRASH(); #else return reinterpret_cast<uint8_t**>(&PC_sig(context)); #endif (js/src/wasm/WasmSignalHandlers.cpp line 427) It seems there is no JIT for ppc64, so JS_CODEGEN_NONE is set.
(In reply to Marcus Comstedt from comment #15) > It seems there is no JIT for ppc64, so JS_CODEGEN_NONE is set. True. Though there is one in the works for Firefox for ppc64le: https://www.talospace.com/2022/02/brief-status-update-on-power9.html
@Marcus, Thank you for all the feedback/work. I'll have a look through it when my time allows me. (In reply to Marcus Comstedt from comment #7) > Created attachment 768147 [details, diff] [details, diff] > Patch to disable SSE stuff in webrtc on non-x86 (see also bug 758308) Yes, that bug. I was thinking about closing that one, and moving its discussion into this one as well, but was not sure about it. I had some chat with upstream regarding this. They suggested to maybe disable it altogether on non-x86 for now. The code, in theory, should work (besides the issue you raise), but it is disabled in SM by default because an activation interface is missing. From what I understood is that if this wasn't the case any site could activate the camera/microphone without notification. It could still be used, but would require an addon that works as a switch for this. Even then, there is a good chance it doesn't work, because many sites would block on basis of the User-Agent string. So, with this there are options to choose from how to handle this: 1) Apply your patch. 2) Backport the upstream mozilla patch, mentioned in bug 758308 (Seamonkey upstream warns that it better should apply clean, else better not use it.) 3) Disable WebRTC completely for non-x86.
@Myckel I guess an option could also be to add a use-flag for webrtc, and arch-mask it for now.
(In reply to Marcus Comstedt from comment #18) > @Myckel > I guess an option could also be to add a use-flag for webrtc, and arch-mask > it for now. Yes, that would be possible as well. I've been looking at the patches upstream send me regarding this. One patch solves the problem as well (it's similar to the one mentioned here https://bugs.gentoo.org/758308#c8), although it needs a small adjustment to work on SM. The other two involve AARCH64, I think it's best to keep those out for now as one needs a lot of changes to many files. So, my suggestion for this part: 1) Add your patch to the gentoo build. 2) Add the webrtc USE flag, unset by default, not arch-mask, but maybe add a notification for whoever sets it. 3) Backport the Mozilla patch send to Seamonkey upstream.
(In reply to Marcus Comstedt from comment #10) > Hm, isn't it strange that it's trying to build its own pixman in the first > place? I mean the ebuild does have a dep on the system pixman: > > >=x11-libs/pixman-0.19.2 The fact that an ebuild lists it as a dependency does not mean Seamonkeys build system can do stupid things. Thanks for catching that one. I'll add --enable-system-pixman as a default.
Btw, www-client/seamonkey-2.53.11.1 (without local patches or EXTRA_ECONF) crashes immediately on arm64 little endian, in the memory allocator of the javascript interpreter. But I guess I should open a separate bug about that...
Created attachment 768500 [details, diff] Patch to disable JIT-specific signal handling when there is no JIT
Created attachment 768502 [details] First screenshot of seamonkey 2.53.11.1 running on ppc64
Ok, so I found a workaround for the JIT crash. It seems like the code was sending a signal for the benefit of JIT, and then the signal handler did not know what to do since there was no JIT. I simply disabled all the signal hulabaloo when there is no JIT. This should fall back to non-signal based communications, just like if signals were not available. So with this latest patch (nojit.patch), seamonkey does start finally. Some colours are wrong as can be seen in the attached screenshot (menu items, tab names, some images), and restore session did not work correctly. But basic functionality seems to be there. (But just like in older seamonkey, trying to browse github gives unsatisfactory results.)
A bunch of JavaScript errors on startup: ---8<--- [calBackendLoader] Using Thunderbird's builtin libical backend JavaScript error: resource://devtools/client/framework/gDevTools.jsm, line 150: TypeError: browser[name] is undefined JavaScript error: resource://devtools/shared/base-loader.js -> resource://devtools/client/framework/browser-menus.js, line 223: TypeError: menu is null JavaScript error: jar:file:///usr/lib64/seamonkey/omni.ja!/components/devtools-startup.js, line 267: NS_ERROR_FILE_NOT_FOUND: JavaScript warning: resource://gre/modules/commonjs/toolkit/loader.js -> resource://fxdevtools-adapters-at-mozilla-dot-org/lib/chromium/root.js, line 269: JavaScript 1.7's legacy generators are deprecated; consider using ES6 generators instead. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function* for details. JavaScript warning: resource://gre/modules/commonjs/toolkit/loader.js -> resource://fxdevtools-adapters-at-mozilla-dot-org/lib/chromium/walker.js, line 697: JavaScript 1.7's legacy generators are deprecated; consider using ES6 generators instead. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function* for details. JavaScript warning: resource://gre/modules/commonjs/toolkit/loader.js -> resource://fxdevtools-adapters-at-mozilla-dot-org/lib/chromium/highlighter.js, line 70: JavaScript 1.7's legacy generators are deprecated; consider using ES6 generators instead. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function* for details. console.error: valence: Message: TypeError: Runtimes is undefined Stack: @resource://fxdevtools-adapters-at-mozilla-dot-org/lib/util/scanner.js:81:3 registerScanner@resource://fxdevtools-adapters-at-mozilla-dot-org/lib/main.js:6:19 @resource://fxdevtools-adapters-at-mozilla-dot-org/lib/main.js:13:3 run@resource://gre/modules/commonjs/sdk/addon/runner.js:143:19 startup/</<@resource://gre/modules/commonjs/sdk/addon/runner.js:83:9 process@resource://gre/modules/Promise-backend.js:928:23 walkerLoop@resource://gre/modules/Promise-backend.js:812:7 scheduleWalkerLoop/<@resource://gre/modules/Promise-backend.js:748:11 ************************* A coding exception was thrown in a Promise resolution callback. See https://developer.mozilla.org/Mozilla/JavaScript_code_modules/Promise.jsm/Promise Full message: TypeError: Runtimes is undefined Full stack: @resource://fxdevtools-adapters-at-mozilla-dot-org/lib/util/scanner.js:81:3 registerScanner@resource://fxdevtools-adapters-at-mozilla-dot-org/lib/main.js:6:19 @resource://fxdevtools-adapters-at-mozilla-dot-org/lib/main.js:13:3 run@resource://gre/modules/commonjs/sdk/addon/runner.js:143:19 startup/</<@resource://gre/modules/commonjs/sdk/addon/runner.js:83:9 process@resource://gre/modules/Promise-backend.js:928:23 walkerLoop@resource://gre/modules/Promise-backend.js:812:7 scheduleWalkerLoop/<@resource://gre/modules/Promise-backend.js:748:11 ************************* console.error: valence: Message: TypeError: Runtimes is undefined Stack: @resource://fxdevtools-adapters-at-mozilla-dot-org/lib/util/scanner.js:81:3 registerScanner@resource://fxdevtools-adapters-at-mozilla-dot-org/lib/main.js:6:19 @resource://fxdevtools-adapters-at-mozilla-dot-org/lib/main.js:13:3 run@resource://gre/modules/commonjs/sdk/addon/runner.js:143:19 startup/</<@resource://gre/modules/commonjs/sdk/addon/runner.js:83:9 process@resource://gre/modules/Promise-backend.js:928:23 walkerLoop@resource://gre/modules/Promise-backend.js:812:7 scheduleWalkerLoop/<@resource://gre/modules/Promise-backend.js:748:11 Document https://www.gentoo.org/ loaded successfully
And this is the error when trying to use session restore: ---8<--- JavaScript error: chrome://communicator/content/aboutSessionRestore.js, line 116: uncaught exception: 2147942487 JavaScript error: chrome://communicator/content/aboutSessionRestore.js, line 116: NS_ERROR_ILLEGAL_VALUE: Illegal value'Illegal value' when calling method: [nsISessionStore::setWindowState] JavaScript error: resource://devtools/client/framework/gDevTools.jsm, line 150: TypeError: browser[name] is undefined JavaScript error: resource://devtools/shared/base-loader.js -> resource://devtools/client/framework/browser-menus.js, line 223: TypeError: menu is null JavaScript error: jar:file:///usr/lib64/seamonkey/omni.ja!/components/devtools-startup.js, line 267: NS_ERROR_FILE_NOT_FOUND:
(In reply to Marcus Comstedt from comment #21) > Btw, www-client/seamonkey-2.53.11.1 (without local patches or EXTRA_ECONF) > crashes immediately on arm64 little endian, in the memory allocator of the > javascript interpreter. > > But I guess I should open a separate bug about that... Yes, please do. Seamonkey currently isn't arm/arm64 keyworded, so we could look at that later, when this PPC64 work has settled. As for the JS engine, good that you got it working. I wouldn't worry too much about the JS errors at this moment, as long as it doesn't crash Seamonkey itself. I've send the SSE patch upstream and I hope they include it in the next release. The other things I'll handle in the ebuild for now, my guess is that most of these things originate from the fact that parts of the code are old/outdated, and should be pushed to newer versions.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=db5b45315b4827253e52bbc1460ac0fbe615708c commit db5b45315b4827253e52bbc1460ac0fbe615708c Author: Myckel Habets <gentoo-bugs@habets-dobben.nl> AuthorDate: 2022-05-08 08:23:57 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-05-10 01:37:04 +0000 www-client/seamonkey: enable elf hack on architectures that support it The old implementation, just disabled elf hack by default. Now we enable this where it is enabled by default by seamonkey itself. According to firefox this breaks with clang, so we copied over the check that firefox uses to disable it on clang builds. Bug: https://bugs.gentoo.org/836319 Signed-off-by: Myckel Habets <gentoo-bugs@habets-dobben.nl> Signed-off-by: Sam James <sam@gentoo.org> www-client/seamonkey/seamonkey-2.53.12.ebuild | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=74052b2f249d7cdde3667fbb0e0f8d184d74fbd7 commit 74052b2f249d7cdde3667fbb0e0f8d184d74fbd7 Author: Myckel Habets <gentoo-bugs@habets-dobben.nl> AuthorDate: 2022-05-06 10:47:34 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-05-10 01:37:02 +0000 www-client/seamonkey: make use of system provided pixman Bug: https://bugs.gentoo.org/836319 Signed-off-by: Myckel Habets <gentoo-bugs@habets-dobben.nl> Signed-off-by: Sam James <sam@gentoo.org> www-client/seamonkey/seamonkey-2.53.11.1-r1.ebuild | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e6b58bdb44bc1af37504d2043ca56fa14a96a44a commit e6b58bdb44bc1af37504d2043ca56fa14a96a44a Author: Myckel Habets <gentoo-bugs@habets-dobben.nl> AuthorDate: 2022-03-30 13:18:21 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-05-10 01:37:01 +0000 www-client/seamonkey: webrtc fixes * Fixes webrtc build for PPC64 through a patch. * Makes webrtc disabled by default through an USE flag. Seamonkey's webrtc should work, but there are a few drawbacks that one should consider against using it. A plugin is needed to activate it, as Seamonkey lacks an interface to do this. Seamonkey deactivates it by default because of severe privacy issues that could arise when not used properly. Another drawback is that many webrtc-enabled websites block Seamonkey through an User-Agent method, which would need a way to work around. Bug: https://bugs.gentoo.org/836319 Signed-off-by: Myckel Habets <gentoo-bugs@habets-dobben.nl> Signed-off-by: Sam James <sam@gentoo.org> www-client/seamonkey/seamonkey-2.53.11.1-r1.ebuild | 553 +++++++++++++++++++++ 1 file changed, 553 insertions(+)
@Marcus Comstedt Version 2.53.12 got accepted into the main gentoo tree last night. This should contain all the contributions you made in one form or another. Could you give it a try on PPC64 (preferably with and without the webrtc USE flag)? If that works, could you also test combinations of the other USE flags? To see if those work and don't "activate" missed build failures. Thank you in advance.
(In reply to Myckel Habets from comment #29) The --disable-elf-hack problem still persists: 0:06.57 File "/tmp/portage/www-client/seamonkey-2.53.12/work/seamonkey-2.53.12/python/mozbuild/mozbuild/configure/__init__.py", line 567, in _value_for_option 0:06.57 % option_string.split('=', 1)[0]) 0:06.57 mozbuild.configure.options.InvalidOptionError: --disable-elf-hack is not available in this configuration 0:06.60 *** Fix above errors and then restart with\ 0:06.60 "./mach build" 0:06.60 gmake: *** [client.mk:109: configure] Error 1 The "elfhack.patch" attached to this issue still applies. After applying "elfhack.patch", 2.53.12 builds, but it does not start. There is a dialog saying The application has been updated, but the SQLite library wasn't updated properly and the application cannot run. Please try to launch the application again. If that should still fail, please try reinstalling it, or contact the support of where you got the application from. When I close the dialog seamonkey quits with a segmentation fault. Now that I mention segmentation faults I remember that I still have EXTRA_ECONF="--enable-system-pixman --disable-debug --disable-tests --disable-jemalloc" in my /etc/portage/env/www-client/seamonkey. I should probably try without that was well, but it will have to wait...
Oops, sorry, I missed the dependency on a newer SQLite (I was building using the "ebuild" command, not "emerge", so it didn't enforce it). After upgrading SQLite seamonkey _does_ start (some wrong colours like before). Still need to check without ExTRA_ECONF.
(In reply to Marcus Comstedt from comment #30) > (In reply to Myckel Habets from comment #29) > > The --disable-elf-hack problem still persists: > > 0:06.57 File > "/tmp/portage/www-client/seamonkey-2.53.12/work/seamonkey-2.53.12/python/ > mozbuild/mozbuild/configure/__init__.py", line 567, in _value_for_option > 0:06.57 % option_string.split('=', 1)[0]) > 0:06.57 mozbuild.configure.options.InvalidOptionError: --disable-elf-hack > is not available in this configuration > 0:06.60 *** Fix above errors and then restart with\ > 0:06.60 "./mach build" > 0:06.60 gmake: *** [client.mk:109: configure] Error 1 > > The "elfhack.patch" attached to this issue still applies. > Ok. That's strange because the ebuild should not pass --disable-elf-hack to the configure any more. I removed that code, to have the configure script check it out by itself (for the most part). I'll dig into this further, see where this comes from. Could you upload the build log from the unpatched version? > Now that I mention segmentation faults I remember that I still have > > EXTRA_ECONF="--enable-system-pixman --disable-debug --disable-tests > --disable-jemalloc" > > in my /etc/portage/env/www-client/seamonkey. I should probably try without > that was well, but it will have to wait... The --enable-system-pixman should not be needed any more, as it is passed by the ebuild now. --disable-debug and --disable-tests should also be handled by the ebuild... I think those things are disabled by default (never looked into detail at this), so if you have issues with removing those, that would be something to look at. Had to dig into the code for --disable-jemalloc, it seems that it's bundled, enabled by default and could be outdated. I think the ebuild needs to pass that configure option based on the architecture, or a fix in upstream. I'll have a look at it.
(In reply to Marcus Comstedt from comment #31) > Oops, sorry, I missed the dependency on a newer SQLite (I was building using > the "ebuild" command, not "emerge", so it didn't enforce it). After > upgrading > SQLite seamonkey _does_ start (some wrong colours like before). > > Still need to check without ExTRA_ECONF. That's the system-sqlite USE-flag and patch. This message and "crash" is introduced by the patch as a check on that the system sqlite is not older than the bundled version.
(In reply to Myckel Habets from comment #32) > Ok. That's strange because the ebuild should not pass --disable-elf-hack to > the configure any more. I removed that code, to have the configure script > check it out by itself (for the most part). I'll dig into this further, see > where this comes from. Could you upload the build log from the unpatched > version? Certainly. I'll attach it as elfhack.log. From the look of things, it's coming from mozcoreconf-v6.eclass. >--disable-debug and --disable-tests should also be handled > by the ebuild... I think those things are disabled by default (never looked > into detail at this), so if you have issues with removing those, that would > be something to look at. I needed EXTRA_ECONF="--disable-debug" or I got several build errors (see debug.log), but I do have the "debug" use flag turn on, so disabling that might also fix the problem. Will try that later. > Had to dig into the code for --disable-jemalloc, it > seems that it's bundled, enabled by default and could be outdated. I think > the ebuild needs to pass that configure option based on the architecture, or > a fix in upstream. I'll have a look at it. Just confirming here that without EXTRA_ECONF="--disable-jemalloc" seamonkey 2.53.12 builds but crashes on startup, as before.
Created attachment 778358 [details] Log from building without elfhack.patch
Created attachment 778361 [details] Log from building without EXTRA_ECONF="--disable-debug" but with USE="debug"
So, regarding debug, yes if I turn of the "debug" use flag then I can remove "--disable-debug" from EXTRA_ECONF. _However_, I do need to keep the following in my env file: CFLAGS="${CFLAGS} -ggdb" CXXFLAGS="${CXXFLAGS} -ggdb" FEATURES="${FEATURES} splitdebug compressdebug -nostrip" Otherwise I get the error in debug2.log. Bizarre.
Created attachment 778394 [details] Log from building with all debug options turned off
(In reply to Marcus Comstedt from comment #38) > Created attachment 778394 [details] > Log from building with all debug options turned off Wow, that's weird. But I don't understand the purpose of elfhack anyway, so that might just be me. As for jemalloc, yes, I try to avoid it on any "special" arches (anything but amd64/maybe x86/arm64 nowadays).
Well, thinking about it some more, the -g flag in CFLAGS does trigger the --disable-elf-hack flag from mozcoreconf-v6.eclass, so with my elfhack.patch maybe --disable-elf-hack actually does do something useful even on ppc64?
Ah, I see how it is. Applying elfhack.patch is necessary if --disable-elf-hack is among the configure arguments, but the reverse is also true; if you apply elfhack.patch then it is necessary to put --disable-elf-hack among the configure arguments. If I _both_ skip applying elfhack.patch and remove -g from CFLAGS, then that also works. So we are down to this: * EXTRA_ECONF="--disable-jemalloc" is needed * elfhack.patch is applicable iff -g is in CFLAGS (due to the check in mozcoreconf-v6.eclass) * USE=debug leads to build failure unless you also have EXTRA_ECONF="--disable-debug" (which probably defeats the purpose of USE=debug anyway...)
By the way, I just tried building with USE=webrtc, but the patch seems to be missing from the archive: ---8<--- * Applying 1009_seamonkey-2.53.3-system_libvpx-1.8.patch ... [ ok ] * Applying 1012_seamonkey-2.53.11.1-ppc64_webrtc_skip_sse2.patch ... /tmp/portage/www-client/seamonkey-2.53.12/temp/environment: line 1932: /tmp/portage/www-client/seamonkey-2.53.12/work/gentoo-seamonkey-patches-2.53.12/USE_flag/1012_seamonkey-2.53.11.1-ppc64_webrtc_skip_sse2.patch: No such file or directory /tmp/portage/www-client/seamonkey-2.53.12/temp/environment: line 1935: /tmp/portage/www-client/seamonkey-2.53.12/work/gentoo-seamonkey-patches-2.53.12/USE_flag/1012_seamonkey-2.53.11.1-ppc64_webrtc_skip_sse2.patch: No such file or d [ !! ]y * ERROR: www-client/seamonkey-2.53.12::gentoo failed (prepare phase): * patch -p1 -p2 failed with /tmp/portage/www-client/seamonkey-2.53.12/work/gentoo-seamonkey-patches-2.53.12/USE_flag/1012_seamonkey-2.53.11.1-ppc64_webrtc_skip_sse2.patch ---8<--- There is no "1012_seamonkey-2.53.11.1-ppc64_webrtc_skip_sse2.patch" in /usr/portage/distfiles/seamonkey-2.53.12-patches.tar.gz. (Nor in seamonkey-2.53.11.1-patches.tar.gz for that matter.)
(In reply to Marcus Comstedt from comment #41) > that also works. So we are down to this: > > * EXTRA_ECONF="--disable-jemalloc" is needed Right, for now this should be added to the ebuild. Later see if this can be fixed in upstream. > * elfhack.patch is applicable iff -g is in CFLAGS (due to the check in > mozcoreconf-v6.eclass) Yeah, I expected to mozcoreconf-v6.eclass be involved. This needs to be fixed in there. > * USE=debug leads to build failure unless you also have > EXTRA_ECONF="--disable-debug" (which probably defeats the purpose of > USE=debug anyway...) I found the code in the seamonkey source that causes this, there is indeed an error in there, which should have been caught by upstream. I'll discuss it with them. I'll see if I can reproduce this on my system, because this should not be PPC64 specific. (In reply to Marcus Comstedt from comment #42) > By the way, I just tried building with USE=webrtc, but the patch seems to be > missing from the archive: > > There is no "1012_seamonkey-2.53.11.1-ppc64_webrtc_skip_sse2.patch" in > /usr/portage/distfiles/seamonkey-2.53.12-patches.tar.gz. (Nor in > seamonkey-2.53.11.1-patches.tar.gz for that matter.) Whoops, error from my side. A fix for this issue was already included upstream. I thought I removed those lines from the ebuild. Thank you for all the feedback. Seems like this still needs a little work.
I had some response from upstream depending the debug build and enable-jemalloc It seems that debug isn't being tested by upstream, and could be broken. If there are build issues they asked to communicate it back to them. (For me less urgent at this point). --enable-jemalloc is deprecated and should not be used (I'll check it with Firefox, see if they have deprecated it as well). So, I'll disable it in the next ebuild.
New no-jit(?) related problem in 2.53.13, build fails: 0:10.10 In file included from /tmp/portage/www-client/seamonkey-2.53.13/work/seamonkey-2.53.13/seamonk/js/src/jit/Unified_cpp_js_src_jit1.cpp:2: 0:10.10 /tmp/portage/www-client/seamonkey-2.53.13/work/seamonkey-2.53.13/js/src/jit/BaselineCacheIRCompiler.cpp: In member function ‘bool BaselineCacheIRCompiler::emitGuardFrameHasNoArgumentsObject()’: 0:10.10 /tmp/portage/www-client/seamonkey-2.53.13/work/seamonkey-2.53.13/js/src/jit/BaselineCacheIRCompiler.cpp:812:64: error: incomplete type ‘js::jit::BaselineFrame’ used in nested name specifier 0:10.10 812 | Address(BaselineFrameReg, BaselineFrame::reverseOffsetOfFlags()), 0:10.10 | ^~~~~~~~~~~~~~~~~~~~
(In reply to Marcus Comstedt from comment #45) > New no-jit(?) related problem in 2.53.13, build fails: > > 0:10.10 In file included from > /tmp/portage/www-client/seamonkey-2.53.13/work/seamonkey-2.53.13/seamonk/js/ > src/jit/Unified_cpp_js_src_jit1.cpp:2: > 0:10.10 > /tmp/portage/www-client/seamonkey-2.53.13/work/seamonkey-2.53.13/js/src/jit/ > BaselineCacheIRCompiler.cpp: In member function ‘bool > BaselineCacheIRCompiler::emitGuardFrameHasNoArgumentsObject()’: > 0:10.10 > /tmp/portage/www-client/seamonkey-2.53.13/work/seamonkey-2.53.13/js/src/jit/ > BaselineCacheIRCompiler.cpp:812:64: error: incomplete type > ‘js::jit::BaselineFrame’ used in nested name specifier > 0:10.10 812 | Address(BaselineFrameReg, > BaselineFrame::reverseOffsetOfFlags()), > 0:10.10 | > ^~~~~~~~~~~~~~~~~~~~ I had a quick look this morning to see if I could find something that would could cause this, but nothing obvious. I just send in a PR for inclusion of seamonkey-2.53.14 into the gentoo tree. When that's done, please check if you can reproduce this in 2.53.14. If this is still present I'll discuss it with seamonkey upstream. P.S. I also disabled elf-hack on ARM64 in this new ebuild (regarding your comment in the closed bug about this).
Created attachment 823651 [details] Build log for 2.53.14 Thank you. Yes, the js::jit::BaselineFrame issue can be reproduced with 2.53.14. I'm attaching a complete build log.
To get the facts right, last version where the build worked was 2.53.12, right?
Correct. I double checked emerge.log, and 2.53.12 was the last version to succeed in installing.
Spend quite some time looking into this, but have little leads on where the problem is. Apparently the jit building got moved around a bit between those two versions, and I want to try something. I guess JS_CODEGEN_NONE isn't completely handled properly during this moving around, and PPC64 depends on it (at least that's what I got from earlier posts) for not building things it shouldn't, as far as I understand. In the file js/src/jit/moz.build change if not CONFIG['ENABLE_ION']: into if CONFIG['JS_CODEGEN_NONE']: And try again building it. Not sure if that helps, because the failing cpp is still in the list to be compiled. Another thing that could work is adding: #include "jit/BaselineFrame.h" to the top part of BaselineCacheIRCompiler.cpp And try to build with that. If that still doesn't work, I'll have to look further.
Ok. The #include "jit/BaselineFrame.h" change is good, but not enough. An #include "jit/BaselineIC.h" also needs to be added at the top of the file. Then seamonkey builds and runs. The moz.build change does not seem to do anything.
(In reply to Marcus Comstedt from comment #51) > Ok. The #include "jit/BaselineFrame.h" change is good, but not enough. > An #include "jit/BaselineIC.h" also needs to be added at the top of the file. > Then seamonkey builds and runs. > > The moz.build change does not seem to do anything. Ok, clear. I'll see how I will include this in the next version.
