emerging new firefox-66.0-r1 ebuild for arm fails with this beauty: 1:10.89 In file included from /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/www-client/firefox-66.0-r1/work/firefox-66.0/ff/js/src/wasm/Unified_cpp_js_src_wasm2.cpp:29: 1:10.89 /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/www-client/firefox-66.0-r1/work/firefox-66.0/js/src/wasm/WasmSignalHandlers.cpp:520:19: error: field 'ufp' has incomplete type 'user_vfp' 1:10.89 struct user_vfp ufp; 1:10.89 ^~~ 1:10.89 /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/www-client/firefox-66.0-r1/work/firefox-66.0/js/src/wasm/WasmSignalHandlers.cpp:520:10: note: forward declaration of 'struct user_vfp' 1:10.89 struct user_vfp ufp; 1:10.89 ^~~~~~~~ 1:10.89 /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/www-client/firefox-66.0-r1/work/firefox-66.0/js/src/wasm/WasmSignalHandlers.cpp:521:23: error: field 'ufp_exc' has incomplete type 'user_vfp_exc' 1:10.89 struct user_vfp_exc ufp_exc; 1:10.89 ^~~~~~~ 1:10.89 /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/www-client/firefox-66.0-r1/work/firefox-66.0/js/src/wasm/WasmSignalHandlers.cpp:521:10: note: forward declaration of 'struct user_vfp_exc' 1:10.89 struct user_vfp_exc ufp_exc; 1:10.89 ^~~~~~~~~~~~ 1:10.89 gmake[4]: *** [/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/www-client/firefox-66.0-r1/work/firefox-66.0/config/rules.mk:1108: Unified_cpp_js_src_wasm2.o] Error 1 this is a cross-compile, but it shouldn't matter.
Created attachment 569968 [details] compressed build.log the full build log
Basically this happens as the build tries to inherit headers which are only present on android. patch to fix it, from #1526653: https://hg.mozilla.org/mozilla-central/rev/322de2cc8019
Created attachment 569970 [details] emerge --info from cross-emerge if someone's interested into the emerge --info, here it is
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d5548320f5a3160b9134274850f6ea76e90ad5fa commit d5548320f5a3160b9134274850f6ea76e90ad5fa Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2019-03-20 15:49:51 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2019-03-20 15:51:59 +0000 www-client/firefox: unbreak arm Add some patches to fix building on arm. Closes: https://bugs.gentoo.org/681036 Closes: https://bugs.gentoo.org/678204 Package-Manager: Portage-2.3.62, Repoman-2.3.12 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> www-client/firefox/Manifest | 2 +- www-client/firefox/firefox-66.0-r1.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
Upstream closed their bug as fixed, but the patch isn't sufficent for fixing the compile. An extended fix would be: diff --git a/js/src/wasm/WasmSignalHandlers.cpp b/js/src/wasm/WasmSignalHandlers.cpp index 488d897..a4a76ee 100644 --- a/js/src/wasm/WasmSignalHandlers.cpp +++ b/js/src/wasm/WasmSignalHandlers.cpp @@ -243,7 +243,6 @@ using mozilla::DebugOnly; // emulation here. #if defined(__linux__) && defined(__arm__) -# define WASM_EMULATE_ARM_UNALIGNED_FP_ACCESS #endif #ifdef WASM_EMULATE_ARM_UNALIGNED_FP_ACCESS or it could be: https://archlinuxarm.org/packages/armv7h/firefox/files/arm.patch
there's a proposed fix from debian, which I think copies over the correct defines from the linux kernel header files: https://salsa.debian.org/mozilla-team/firefox/commit/fd6847c9416f9eebde636e21d794d25d1be8791d still no upstream patch
I just tested the "disable" fix, and also made a patch like that debian one, and both allow firefox to compile. The missing structs are apparently only in the android bionic libc, so I have no idea where they get "not in all linux distros" or "tier 3" since android/bionic is *not* linux or a distro... Anyway, firefox will *not* build on arm without a fix, so we could really use a patch in the tree for this; the debian approach seems fine.
Created attachment 590540 [details, diff] arm fp reg patch plucked from debian gitlab
Hit this on armv7a (cubieboard2) compiling firefox-68.1.0. The attached patch worked for me.
Do you think you could head over to mozbugtracker and help me to annoy a few of their dev's? It seems that this is a bit of a deadlock situation, concerning android vs gnu headers and license issues.
Sorry, I forgot to subscribe. Do you mean me? I'd happily add a +1 if you point me at a bug.
yeah, I meant you. It is mozbg #1526653, as it's mentioned in the see also section of this bug. The problem with this bug is, that it would need to add defines from the gnu linux header files to the firefox code, which would create a license issue for mozilla, and so they rejected that idea. Fair enough, but the corresponding android header files are identical. This all comes down to the mozilla policy of not caring too much about arm targets other than android.
Right, I missed that somehow. Just added my $0.02 to the upstream bug, for what it's worth.
there's a proper patch in the patchset of firefox-71.0, but upstream still doesn't care :(
(In reply to tt_1 from comment #14) > there's a proper patch in the patchset of firefox-71.0, but upstream still > doesn't care :( so you did managed to build it on armhf ? or armv7 ?
sure, with said patch from debian it's no problem on armv7a-unknown-linux-gnueabihf, but upstream is relucant to fix the mess they created in the first place.
I found out, that my CPU has armv7 support, so that's enough :P Only Rpi1 and RpiZero has pure armhf, which probably no-one will use for browsing internet with Firefox.
Is this still an issue with >=www-client/firefox-78.3.1?
the upstream bug is still unresolved, so yes this is still a problem with thunderbird, firefox and spidermonkey upstream claims it's some sort of licensing issue for why they don't want to merge the patch, and maybe it will turn into a permabug therefore :-/
But we are shipping a patch for this, right?
that's correct
OK, so I would like to keep this bug as resolved because the issue is addressed in Gentoo's package and the patch we carry has a reference to this bug.
upstream has fixed this now for good, the patches are in two seperate bugs - the order matters and is correct this way: https://bugzilla.mozilla.org/show_bug.cgi?id=1723930 https://bugzilla.mozilla.org/show_bug.cgi?id=1587757 I'll ask for a backport to the 91.0-esr branch
(In reply to tt_1 from comment #23) > upstream has fixed this now for good, the patches are in two seperate bugs - > the order matters and is correct this way: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1723930 > https://bugzilla.mozilla.org/show_bug.cgi?id=1587757 > > I'll ask for a backport to the 91.0-esr branch third patch needed to fix wasm https://bugzilla.mozilla.org/show_bug.cgi?id=1724475 all three relevant patches are already backported and merged into firefox-91esr, so for firefox-91.1.0 the 0011* patch should be removed from the patchset.
