Created attachment 639626 [details] build.log [...] checking for the Bing API key... no checking for the Adjust SDK key... no checking for the Leanplum SDK key... no checking for the Pocket API key... no ERROR: --disable-skia is not supported anymore *** Fix above errors and then restart with\ "make -f client.mk build" make: *** [client.mk:362: configure] Error 1 * ERROR: www-client/seamonkey-2.53.2::gentoo failed (configure phase): * emake failed
Created attachment 639628 [details] emerge --info
It seems like mozilla made the choice that skia is a required component Firefox, and Seamonkey backported this. So a build without skia isn't possible any more. My plan is remove the endianess-check and the skia-related compile options from the ebuild. In principle this solves this bug, but there is a chance building Seamonkey on PPC64 will fail, due to the endianess. In that case, bugs need to be filed upstream.
IME trying to file upstream bugs with skia is a dead end; they don't care that their crap is broken. Keeping a huge local patchset is the only what to get it to work properly. I have one here: https://github.com/zeldin/chromium_be/blob/master/chromium-89.0.4389.114/skia.patch
While that doesn't sound crazy, I still think it'd be worth filing bugs so we can ask some of the people we know about them and try poke things internally if necessary. Not promising that will work, but my point is we'd need tangible bugs/patches submitted to link to, rather than complaining in abstract. Would you consider submitting those patches somewhere if you haven't already?
@sam Here's an example of a patch I submitted, and all the good it did me: https://skia-review.googlesource.com/c/skia/+/342921 Not exactly my idea of a fruitful activity.
With "upstream" I meant Seamonkey upstream (or Mozilla/Firefox), not skia itself. Mozilla/Firefox devs have committed themselves for supporting skia by accepting patches for all the platforms that they support (including big endian archs). See https://bugzilla.mozilla.org/show_bug.cgi?id=1323303. I've already talked with Seamonkey upstream regarding skia and they said they backported https://bugzilla.mozilla.org/show_bug.cgi?id=1144632 this afternoon (will get into the patch queue). However, they don't have any big endian systems to test it. The best I can do now is fix the ebuild for the next release (as it seems to be broken for PPC64 at this moment any way) and see if it build and works.
> However, they don't have any big endian systems to test it. Would it help if I donated a Raspberry Pi 3?
(In reply to Marcus Comstedt from comment #7) > Would it help if I donated a Raspberry Pi 3? Hehe. But an interesting point! Are there any distros officially supporting BE on ARM hardware? I only know of https://github.com/zeldin/linux-1/releases
Distros supporting 64-bit ARM in big endian mode? Yes. It's called Gentoo. :-)
(In reply to Marcus Comstedt from comment #7) > > However, they don't have any big endian systems to test it. > > Would it help if I donated a Raspberry Pi 3? Hmmm... I wasn't aware R-Pi's are big endian. Got one somewhere here, might set it up to do some testing myself. :-D
@Marcus: Well, then Gentoo FTW! ;) Didn't find BigEndian stages on the mirror, so I thought there was no official support. Did not do any further research as I got no Pi. @Myckel: Not per default, only if you set it up to be BigEndian. Probably this is as easy as on ppc64 where you only need to set an option in the kernel .config. After that you would 'only' need BE toolchain and userland. And it looks like the Pi4 ist out of question at the moment: https://mail-index.netbsd.org/port-arm/2020/12/03/msg007117.html
@Myckel Like all modern architectures (meaning anything newer than x86), ARM is bi- endian. All 64-bit cores from ARM Ltd (e.g. Cortex A-5x and A-7x) can switch endianness at runtime, which also makes it possible to run KVM guests with a different endianness than the host system. If you want to run big endian bare metal (i.e. not in a VM) on Pi3, there are some kernel bugs which need fixing first. I have a fixed kernel build here: https://github.com/zeldin/linux-1/releases/tag/pi3be_v0.2 There is also a complete SD-card image with a Gentoo installation at the same place. @ernsteiswuerfel There are no official stages AFAIK (but I have unofficial ones if you want them), probably blocked by https://bugs.gentoo.org/782076 But there is an official profile: [13] default/linux/arm64/17.0/big-endian (exp) * This was added after I made the initial Pi3BE release, but before I made the second one, so the latest build uses this official profile. Pi4 is fine, the only problem I have found is the USB3 controller on PCIe (the XHCI driver _should_ work fine on BE, so I don't know what the problem is, possibly some issue with the PCIe root complex driver). CM4 (with IO board) should work as it doesn't include the USB3 controller but has USB via DWC instead just like Pi3.
I've just put in a PR for a version bump of seamonkey, that also "fixes" this bug (it removes the check and the invalid configuration option) and puts in the upstream patch. It seems that setting up a big endian system on basis of a R-Pi takes more time than I have, so if others have ready access to such system, feel free to test if it works. If you run into issues, please open a new bug for that (here, or upstream).
Thanks for the patches, I'll add them to media-gfx/skia::guru
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=600d93ba48fad2419b0cc20874b336b31902edb3 commit 600d93ba48fad2419b0cc20874b336b31902edb3 Author: Myckel Habets <gentoo-bugs@habets-dobben.nl> AuthorDate: 2022-03-26 14:22:48 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-03-27 00:24:11 +0000 www-client/seamonkey: bump version to 2.53.11.1 Additionally: * Remove check for big endian and conditional --disable-skia configuration option. * Include an upstream patch that fixes the skia build on big endian systems. Bug: https://bugs.gentoo.org/723372 * Remove a sed that suppresses format errors on gcc-9. Signed-off-by: Myckel Habets <gentoo-bugs@habets-dobben.nl> Closes: https://github.com/gentoo/gentoo/pull/24760 Signed-off-by: Sam James <sam@gentoo.org> www-client/seamonkey/Manifest | 3 + www-client/seamonkey/seamonkey-2.53.11.1.ebuild | 543 ++++++++++++++++++++++++ 2 files changed, 546 insertions(+)
Created attachment 768012 [details] build.log (ppc64, 2.53.11.1) First I needed to comment out "mozconfig_annotate '' --disable-elf-hack" in the ebuild or I get this error: [...] 0:06.47 mozbuild.configure.options.InvalidOptionError: --disable-elf-hack is not available in this configuration After commenting out the '--disable-elf-hack' line the 2.53.11.1 build continues but fails later with : [...] 31:06.70 In file included from /var/tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/security/sandbox/chromium/sandbox/linux/bpf_dsl/dump_bpf.cc:16: 31:06.70 /var/tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/security/sandbox/chromium/sandbox/linux/bpf_dsl/seccomp_macros.h:290:2: error: #error Unsupported target platform 31:06.70 290 | #error Unsupported target platform 31:06.70 | ^~~~~ 31:07.00 /var/tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/security/sandbox/chromium/sandbox/linux/bpf_dsl/dump_bpf.cc: In function 'const char* sandbox::bpf_dsl::{anonymous}::DataOffsetName(size_t)': 31:07.00 /var/tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/security/sandbox/chromium/sandbox/linux/bpf_dsl/dump_bpf.cc:68:10: error: 'SECCOMP_NR_IDX' was not declared in this scope; did you mean 'SECCOMP_RET_KILL'? 31:07.00 68 | case SECCOMP_NR_IDX: 31:07.00 | ^~~~~~~~~~~~~~ 31:07.00 | SECCOMP_RET_KILL 31:07.00 /var/tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/security/sandbox/chromium/sandbox/linux/bpf_dsl/dump_bpf.cc:70:10: error: 'SECCOMP_ARCH_IDX' was not declared in this scope 31:07.00 70 | case SECCOMP_ARCH_IDX: 31:07.00 | ^~~~~~~~~~~~~~~~ 31:07.01 /var/tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/security/sandbox/chromium/sandbox/linux/bpf_dsl/dump_bpf.cc:72:10: error: 'SECCOMP_IP_LSB_IDX' was not declared in this scope 31:07.01 72 | case SECCOMP_IP_LSB_IDX: 31:07.01 | ^~~~~~~~~~~~~~~~~~ 31:07.01 /var/tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/security/sandbox/chromium/sandbox/linux/bpf_dsl/dump_bpf.cc:74:10: error: 'SECCOMP_IP_MSB_IDX' was not declared in this scope 31:07.01 74 | case SECCOMP_IP_MSB_IDX: 31:07.01 | ^~~~~~~~~~~~~~~~~~ 31:07.01 /var/tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/security/sandbox/chromium/sandbox/linux/bpf_dsl/dump_bpf.cc: In function 'void sandbox::bpf_dsl::{anonymous}::AppendInstruction(std::string*, size_t, const sock_filter&)': 31:07.01 /var/tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/security/sandbox/chromium/sandbox/linux/bpf_dsl/dump_bpf.cc:90:42: error: 'SECCOMP_ARG_LSB_IDX' was not declared in this scope 31:07.02 90 | if (maybe_argno < 6 && insn.k == SECCOMP_ARG_LSB_IDX(maybe_argno)) { 31:07.02 | ^~~~~~~~~~~~~~~~~~~ 31:07.02 /var/tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/security/sandbox/chromium/sandbox/linux/bpf_dsl/dump_bpf.cc:93:30: error: 'SECCOMP_ARG_MSB_IDX' was not declared in this scope 31:07.02 93 | insn.k == SECCOMP_ARG_MSB_IDX(maybe_argno)) { 31:07.02 | ^~~~~~~~~~~~~~~~~~~ 31:07.08 gmake[4]: *** [/var/tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/config/rules.mk:1033: dump_bpf.o] Error 1 [...] So in it's current state 2.53.11.1 is not buildable (yet) on ppc64.
@ernsteiswuerfel Sigh, looks like more chromium cruft has been cargo-culted into seamonkey... chromium's sandbox (like most chromium components) is broken on ppc64. Here's a patch: https://github.com/zeldin/chromium_be/blob/master/chromium-89.0.4389.114/sandbox.patch
@Marcus: Thanks! This is quite a large patch. Will take some time to find and try the relevant parts concerning seamonkey. If I succeed at all...
@ernsteiswuerfel Gentoo already carries most of the patch for www-client/chromium (unless it was removed again), I just added the 11 lines needed for BE support.
Closing this bug, as its part has been completed. I made a new bug tracker to handle PPC64 support (and BE in general): Bug 836319 Please continue discussion there.
