Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 836319 - www-client/seamonkey: restoring PPC64 support
Summary: www-client/seamonkey: restoring PPC64 support
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: PPC64 Linux
: Normal normal (vote)
Assignee: Myckel Habets
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-03-28 10:34 UTC by Myckel Habets
Modified: 2022-05-16 07:07 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Patch to fix "--disable-elf-hack is not available in this configuration" build error (elfhack.patch,1.06 KB, patch)
2022-03-29 14:34 UTC, Marcus Comstedt
Details | Diff
Patch to disable SSE stuff in webrtc on non-x86 (see also bug 758308) (webrtc.patch,954 bytes, patch)
2022-03-29 14:36 UTC, Marcus Comstedt
Details | Diff
Patch to fix chromium sandbox build errors on ppc64 (sandbox.patch,15.68 KB, patch)
2022-03-29 14:36 UTC, Marcus Comstedt
Details | Diff
Patch to fix incorrect include guard in nsEmbedFunctions.cpp (xre-sandbox.patch,871 bytes, patch)
2022-03-29 16:03 UTC, Marcus Comstedt
Details | Diff
Patch to add missing global mutex (ipc.patch,906 bytes, patch)
2022-03-29 16:03 UTC, Marcus Comstedt
Details | Diff
Patch to disable JIT-specific signal handling when there is no JIT (nojit.patch,1.02 KB, patch)
2022-04-02 10:38 UTC, Marcus Comstedt
Details | Diff
First screenshot of seamonkey 2.53.11.1 running on ppc64 (monkey.png,352.39 KB, image/png)
2022-04-02 10:39 UTC, Marcus Comstedt
Details
Log from building without elfhack.patch (elfhack.log,23.55 KB, text/plain)
2022-05-12 16:23 UTC, Marcus Comstedt
Details
Log from building without EXTRA_ECONF="--disable-debug" but with USE="debug" (debug.log.xz,157.20 KB, application/x-xz)
2022-05-12 16:26 UTC, Marcus Comstedt
Details
Log from building with all debug options turned off (debug2.log.xz,528.73 KB, application/x-xz)
2022-05-12 20:25 UTC, Marcus Comstedt
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Myckel Habets 2022-03-28 10:34:38 UTC
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
Comment 1 Myckel Habets 2022-03-28 10:39:54 UTC
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
Comment 2 Marcus Comstedt 2022-03-28 11:27:24 UTC
>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.
Comment 3 Myckel Habets 2022-03-28 13:02:22 UTC
(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.
Comment 4 Marcus Comstedt 2022-03-28 13:08:15 UTC
@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.
Comment 5 Myckel Habets 2022-03-28 13:50:23 UTC
Great!

Even if you have things that seem to progress the build a little further, share them here.
Comment 6 Marcus Comstedt 2022-03-29 14:34:46 UTC
Created attachment 768146 [details, diff]
Patch to fix "--disable-elf-hack is not available in this configuration" build error
Comment 7 Marcus Comstedt 2022-03-29 14:36:10 UTC
Created attachment 768147 [details, diff]
Patch to disable SSE stuff in webrtc on non-x86 (see also bug 758308)
Comment 8 Marcus Comstedt 2022-03-29 14:36:39 UTC
Created attachment 768148 [details, diff]
Patch to fix chromium sandbox build errors on ppc64
Comment 9 Marcus Comstedt 2022-03-29 14:42:55 UTC
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...
Comment 10 Marcus Comstedt 2022-03-29 14:56:53 UTC
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
Comment 11 Marcus Comstedt 2022-03-29 15:45:23 UTC
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...
Comment 12 Marcus Comstedt 2022-03-29 16:03:02 UTC
Created attachment 768152 [details, diff]
Patch to fix incorrect include guard in nsEmbedFunctions.cpp
Comment 13 Marcus Comstedt 2022-03-29 16:03:52 UTC
Created attachment 768153 [details, diff]
Patch to add missing global mutex
Comment 14 Marcus Comstedt 2022-03-29 16:11:14 UTC
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.
Comment 15 Marcus Comstedt 2022-03-29 21:12:28 UTC
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.
Comment 16 ernsteiswuerfel archtester 2022-03-29 21:19:49 UTC
(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
Comment 17 Myckel Habets 2022-03-30 07:42:34 UTC
@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.
Comment 18 Marcus Comstedt 2022-03-30 09:00:42 UTC
@Myckel
I guess an option could also be to add a use-flag for webrtc, and arch-mask it for now.
Comment 19 Myckel Habets 2022-03-30 10:34:07 UTC
(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.
Comment 20 Myckel Habets 2022-03-30 13:34:44 UTC
(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.
Comment 21 Marcus Comstedt 2022-04-02 09:12:33 UTC
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...
Comment 22 Marcus Comstedt 2022-04-02 10:38:02 UTC
Created attachment 768500 [details, diff]
Patch to disable JIT-specific signal handling when there is no JIT
Comment 23 Marcus Comstedt 2022-04-02 10:39:30 UTC
Created attachment 768502 [details]
First screenshot of seamonkey 2.53.11.1 running on ppc64
Comment 24 Marcus Comstedt 2022-04-02 10:44:01 UTC
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.)
Comment 25 Marcus Comstedt 2022-04-02 14:42:13 UTC
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
Comment 26 Marcus Comstedt 2022-04-02 14:52:51 UTC
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:
Comment 27 Myckel Habets 2022-04-04 11:02:09 UTC
(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.
Comment 28 Larry the Git Cow gentoo-dev 2022-05-10 01:37:14 UTC
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(+)
Comment 29 Myckel Habets 2022-05-10 06:56:03 UTC
@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.
Comment 30 Marcus Comstedt 2022-05-11 20:41:24 UTC
(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...
Comment 31 Marcus Comstedt 2022-05-12 05:32:16 UTC
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.
Comment 32 Myckel Habets 2022-05-12 07:08:08 UTC
(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.
Comment 33 Myckel Habets 2022-05-12 07:11:25 UTC
(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.
Comment 34 Marcus Comstedt 2022-05-12 16:21:51 UTC
(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.
Comment 35 Marcus Comstedt 2022-05-12 16:23:33 UTC
Created attachment 778358 [details]
Log from building without elfhack.patch
Comment 36 Marcus Comstedt 2022-05-12 16:26:16 UTC
Created attachment 778361 [details]
Log from building without EXTRA_ECONF="--disable-debug" but with USE="debug"
Comment 37 Marcus Comstedt 2022-05-12 20:24:20 UTC
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.
Comment 38 Marcus Comstedt 2022-05-12 20:25:04 UTC
Created attachment 778394 [details]
Log from building with all debug options turned off
Comment 39 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-05-12 20:26:22 UTC
(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).
Comment 40 Marcus Comstedt 2022-05-12 20:31:50 UTC
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?
Comment 41 Marcus Comstedt 2022-05-12 20:49:21 UTC
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...)
Comment 42 Marcus Comstedt 2022-05-12 21:02:49 UTC
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.)
Comment 43 Myckel Habets 2022-05-13 07:34:55 UTC
(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.
Comment 44 Myckel Habets 2022-05-16 07:07:42 UTC
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.