| Summary: | www-client/firefox-135.0.1 build error on ARMv7: unresolved import 'simd_funcs' | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Marius Dinu <marius+gentoo> |
| Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | marius+gentoo |
| Priority: | Normal | Keywords: | PATCH |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugzilla.mozilla.org/show_bug.cgi?id=1953340 https://github.com/chromium/chromium/pull/280 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 371525 | ||
| Attachments: |
build log, gzipped because of upload limit
emerge info firefox 136.0 +clang -jumbo-build |
||
|
Description
Marius Dinu
2025-02-26 13:06:59 UTC
Created attachment 919928 [details]
build log, gzipped because of upload limit
Created attachment 919929 [details]
emerge info
I wonder if you can get around it with EXTRA_ECONF="--disable-rust-simd" - I don't remember if the build system accepts 'disable' flag for it, but you could try. Firefox hasn't had an ~arm (32bit) keyword for a long time and the remnants were cleaned out. By that definition, arm isn't supported, but I imagine you can get around minor issues on your own. It may make sense for that to be a whitelist instead (amd64/arm64) for rust-simd. (In reply to Sam James from comment #4) > It may make sense for that to be a whitelist instead (amd64/arm64) for > rust-simd. Indeed, good point! Will do that with the next version bump. > Firefox hasn't had an ~arm (32bit) keyword for a long time and the remnants were cleaned out. By that definition, arm isn't supported, but I imagine you can get around minor issues on your own.
I removed those lines and build went on, but eventually stopped with another error that I have no ideea how to solve.
I can immediately say from your previous build.log that using gcc and "-jumbo-build" is often failing for me too. You should attempt to use clang to compile without jumbo-build. If it still fails with "+clang -jumbo-build", post the build.log and I'll take a look. No promises though, I don't have arm hardware or any experience in arm. You should also always check upstream bugzilla. While arm isn't _officially_ supported by Mozilla, they accept patches from people who provide them, and I'm aware of at least one person compiling Firefox on arm using Gentoo. +clang -jumbo-build stops with this error: 68:19.42 [glslopt 0.1.11] cargo:warning=In file included from glsl-optimizer/src/compiler/glsl_types.cpp:26: 68:19.43 [glslopt 0.1.11] cargo:warning=In file included from glsl-optimizer/src/compiler/glsl/glsl_parser_extras.h:34: 68:19.44 [glslopt 0.1.11] cargo:warning=In file included from glsl-optimizer/src/compiler/glsl/glsl_symbol_table.h:28: 68:19.45 [glslopt 0.1.11] cargo:warning=/var/tmp2/portage/www-client/firefox-135.0.1/work/firefox_build/dist/stl_wrappers/new:62:15: fatal error: 'new' file not found 68:19.46 [glslopt 0.1.11] cargo:warning= 62 | #include_next <new> 68:19.46 [glslopt 0.1.11] cargo:warning= | ^~~~~ The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7dfd8a45f803cd33f4714dbcc664fc965a5748d9 commit 7dfd8a45f803cd33f4714dbcc664fc965a5748d9 Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2025-03-03 20:13:21 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2025-03-03 20:16:59 +0000 www-client/firefox: add 136.0 - add a patch that's currently being worked upstream which fixes runtime issues when compiled with gcc and lto, - attempt removing "*bgo-925101-force-software-rendering-during-pgo-build.patch" as it's supposed to be fixed by mesa updates, - disable pref "permissions.manager.remote.enabled" by default - can be enabled by corporations managing their browsers via remote-settings, - handle rust-simd by enabling it on supported arches, so unkeyworded arches can probably compile the browser with --disable-rust-simd by default without editing the ebuild, - increase nss, icu and libpng version requirements, - remove our custom patch enabling vaapi on all amd cards since it's merged upstream, - remove our custom system-av1 & system-libvpx patches as they've been merged upstream. Bug: https://bugs.gentoo.org/950229 Bug: https://bugs.gentoo.org/950305 Signed-off-by: Joonas Niilola <juippis@gentoo.org> www-client/firefox/Manifest | 102 ++ www-client/firefox/files/gentoo-default-prefs.js | 3 + www-client/firefox/firefox-136.0.ebuild | 1382 ++++++++++++++++++++++ 3 files changed, 1487 insertions(+) (In reply to Marius Dinu from comment #8) > +clang -jumbo-build stops with this error: > > 68:19.42 [glslopt 0.1.11] cargo:warning=In file included from > glsl-optimizer/src/compiler/glsl_types.cpp:26: > 68:19.43 [glslopt 0.1.11] cargo:warning=In file included from > glsl-optimizer/src/compiler/glsl/glsl_parser_extras.h:34: > 68:19.44 [glslopt 0.1.11] cargo:warning=In file included from > glsl-optimizer/src/compiler/glsl/glsl_symbol_table.h:28: > 68:19.45 [glslopt 0.1.11] > cargo:warning=/var/tmp2/portage/www-client/firefox-135.0.1/work/ > firefox_build/dist/stl_wrappers/new:62:15: fatal error: 'new' file not found > 68:19.46 [glslopt 0.1.11] cargo:warning= 62 | #include_next <new> > 68:19.46 [glslopt 0.1.11] cargo:warning= | ^~~~~ Hard to say from this snippet, would need a full build.log. But it does seem jumbo-build related. 136.0 had "unified build" fixes which often help with -jumbo-build and I didn't personally hit any issues when testing it this time. Also the rust-simd is now handled better for unkeyworded arches. Please give 136.0 a try! Created attachment 920289 [details]
firefox 136.0 +clang -jumbo-build
The simd error is fixed. The "fatal error: 'new' file not found" error remains. Build with +clang +jumbo-build fails the same way. I'm doing -clang +jumbo-build now. It seems to have passed the part that failed with clang but it's still compiling. I expect it to take 2~3 days. -clang +jumbo-build finishes compiling without errors, but firefox crashes on start with a SIGBUS error. Could you share a backtrace? Kernel shows:
[ 135.854777] [ T813] Alignment trap: not handling instruction f4400adf at [<ad656b58>]
[ 135.863596] [ T813] 8<--- cut here ---
[ 135.867831] [ T813] Unhandled fault: alignment exception (0x801) at 0xa9288864
[ 135.875913] [ T813] [a9288864] *pgd=09c5e835, *pte=592d975f, *ppte=592d9c7f
Strace shows:
[pid 963] --- SIGBUS {si_signo=SIGBUS, si_code=BUS_ADRALN, si_addr=0xa8e2f864} ---
[pid 963] +++ killed by SIGBUS +++
I can give you the complete log, but I can't see anything else interesting in it.
I can compile firefox with USE=debug if you want, but it will take another 2 days...
USE=debug is for assertions, not debug symbols. I need a backtrace from gdb/lldb (see https://wiki.gentoo.org/wiki/Debugging). strace is for syscalls, rather than debugging crashes. I may be able to guess the problem if you can show me a backtrace even without debugging symbols. I never used gdb before. After googling, I did this:
gdb /usr/lib/firefox/firefox
>> catch signal 10
>> run
[...some output...]
Thread 5 "IPC I/O Parent" hit Catchpoint 1 (signal SIGBUS), 0xacef4b5c in ?? () from /usr/lib/firefox/libxul.so
Now I'm doing
FEATURES="installsources splitdebug compressdebug -nostrip" CFLAGS="-ggdb3" emerge firefox
(In reply to Marius Dinu from comment #18) > I never used gdb before. After googling, I did this: > > gdb /usr/lib/firefox/firefox > >> catch signal 10 > >> run > [...some output...] > Thread 5 "IPC I/O Parent" hit Catchpoint 1 (signal SIGBUS), 0xacef4b5c in ?? > () from /usr/lib/firefox/libxul.so > When that happens, please run "bt" and hit enter, and show the output of that (once you have good debugging symbols). > Now I'm doing > FEATURES="installsources splitdebug compressdebug -nostrip" CFLAGS="-ggdb3" > emerge firefox Make sure you have debugedit installed first. You also want something like "-O2 -ggdb3" instead... and to do it for CXXFLAGS too. I recommend following the wiki page carefully. Sorry for late reply. Firefox with -ggdb won't build. Rust exceeds 3GB allocated memory, so no matter how much swap I add, it crashes with an "out of memory" error. With just FEATURES="installsources splitdebug compressdebug -nostrip": Thread 5 "IPC I/O Parent" hit Catchpoint 1 (signal SIGBUS), 0xacef4b5c in mojo::core::ports::Event::PortDescriptor::PortDescriptor() () from /usr/lib/firefox/libxul.so (gdb) bt #0 0xacef4b5c in mojo::core::ports::Event::PortDescriptor::PortDescriptor() () from /usr/lib/firefox/libxul.so #1 0xacf05504 in mojo::core::ports::Node::MergePorts(mojo::core::ports::PortRef const&, mojo::core::ports::NodeName const&, mojo::core::ports::PortName const&) () from /usr/lib/firefox/libxul.so #2 0xacf56d64 in mozilla::ipc::NodeController::OnAcceptInvite(mojo::core::ports::NodeName const&, mojo::core::ports::NodeName const&, mojo::core::ports::PortName const&) () from /usr/lib/firefox/libxul.so #3 0xacf57ee0 in mozilla::ipc::NodeChannel::OnMessageReceived(mozilla::UniquePtr<IPC::Message, mozilla::DefaultDelete<IPC::Message> >) () from /usr/lib/firefox/libxul.so #4 0xacefb294 in IPC::Channel::ChannelImpl::ProcessIncomingMessages() () from /usr/lib/firefox/libxul.so #5 0xacefbf30 in IPC::Channel::ChannelImpl::OnFileCanReadWithoutBlocking(int) () from /usr/lib/firefox/libxul.so #6 0xacee2634 in base::MessagePumpLibevent::OnLibeventNotification(int, short, void*) () from /usr/lib/firefox/libxul.so #7 0xab694500 in ?? () from /usr/lib/libevent-2.1.so.7 Backtrace stopped: previous frame identical to this frame (corrupt stack?) I guess it's because it's packed: https://searchfox.org/mozilla-central/source/ipc/chromium/src/mojo/core/ports/event.h#69 Try patching out the '#pragma pack(push, 1)' and '#pragma pack(pop)' lines (see https://wiki.gentoo.org/wiki//etc/portage/patches and https://wiki.gentoo.org/wiki/Creating_a_patch). If that works, please create a report upstream with that backtrace and the workaround patch, and see what they say. It works. Bug report created: https://bugzilla.mozilla.org/show_bug.cgi?id=1953340 Thank you! Thank you both! |
