Created attachment 889551 [details] build log (bzip2 compressed) I'm trying to emerge the newest Firefox release for my raspberry pi's but it keeps failing with this error: 166:35.40 In file included from Unified_cpp_sandbox_linux2.cpp:101: 166:35.40 /var/tmp/portage/www-client/firefox-124.0.2/work/firefox-124.0.2/security/sandbox/linux/SandboxFilter.cpp:957:7: error: use of undeclared identifier '__NR_epoll_wait' Seems strange as the previous version (124.0.1) built just fine on the same machine.
Created attachment 889552 [details] emerge --info =www-client/firefox-124.0.2
Hmm this is a case of mixing stable and unstable packages.
(In reply to Joonas Niilola from comment #2) > Hmm this is a case of mixing stable and unstable packages. ... or maybe not directly, because I seem to have the new syscall defines in glibc-2.38. But I now see you're using a very ancient kernel. Looks like the new syscall was added between kernels 5.10 and 5.15. I don't know if I want to create ebuild hacks for an unstable rapidly moving desktop package that requires kernel >5.10. It is the patch 0029-bgo-928137-add-epoll_pwait2-syscall-to-sandbox.patch that was added between 124.0.1 and 124.0.2. Gentoo bug #928137 and upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1889045 - you can make a local edit removing that patch. But be aware, this patch should be landing upstream ~soon so you're required to update that kernel soon if you want to stick using Firefox rapid release.
It is failing on a asahi 6.6 based kernel and glibc-2.39 as well (clang).
This is reproducible on all my Apple Silicon Macs with the latest glibc and a new-ish kernel. Kernel: sys-kernel/asahi-sources-6.6.0_p16 glibc: sys-libs/glibc-2.39-r2
the patch is broken. on arm64 as epoll_wait and thus __NR_epoll_wait doesn't exists. The patch assumes that if __NR_epoll_pwait2 is defined __NR_epoll_wait will be as well. This is in general not true.
Created attachment 889575 [details, diff] Fixed 0029-bgo-928137-add-epoll_pwait2-syscall-to-sandbox.patch builds on arm64 I've attached a fixed version which doesn't assume that epoll_wait exists if epoll_pwait2 exists. Should fix build on the somewhat releveant arches arm64, longarch64, and riscv.
Thanks, seems to have compiled on amd64 as well!
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=015c1a9499ecffda2d743275baab1d6304fd9e1e commit 015c1a9499ecffda2d743275baab1d6304fd9e1e Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2024-04-06 16:14:23 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2024-04-06 16:14:23 +0000 www-client/firefox: arm64 build fix for 124.0.2 Closes: https://bugs.gentoo.org/928664 Signed-off-by: Joonas Niilola <juippis@gentoo.org> www-client/firefox/Manifest | 2 +- www-client/firefox/firefox-124.0.2.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
has arm been tested yet with the new patch?
Firefox doesn't have ~arm keyword in Gentoo, and to my knowledge upstream also doesn't do arm builds. So I don't think it's been publicly tested at least anywhere.
I also see no reason to believe the new patch wouldn't work, given what the error was...?
the patch is build/run tested on arm64 by me. 32-bit arm shouldn't have had a problem with the original patch as it has the epoll_wait syscall.
(In reply to Janne Grunau from comment #13) > the patch is build/run tested on arm64 by me. 32-bit arm shouldn't have had > a problem with the original patch as it has the epoll_wait syscall. thanks, I'll still give it a try once the 23.0 profile upgrade is through
I've just hit this bug today, but I've noticed I have an older patch
(In reply to Michał Dec from comment #15) > I've just hit this bug today, but I've noticed I have an older patch emerge --sync and try again. Make sure your Manifest file lists the file "firefox-124-patches-04.tar.xz"
