Re: firefox102 problems (one minor, one new?)

[Chavdar Ivanov <ci4ic4%gmail.com@localhost>]

On Thu, 26 Oct 2023 at 20:28, David Brownlee <abs%absd.org@localhost> wrote:
>
> On Thu, 26 Oct 2023 at 20:00, David Brownlee <abs%absd.org@localhost> wrote:
> >
> > On Thu, 26 Oct 2023 at 18:47, David Brownlee <abs%absd.org@localhost> wrote:
> > >
> > > On Thu, 26 Oct 2023 at 14:02, Greg Troxel <gdt%lexort.com@localhost> wrote:
> > > >
> > > > I have netbsd-10 amd64 system that I keep up to date along the netbsd-10
> > > > branch and along pkgsrc HEAD.
> > > >
> > > > Recently, firefox102 failed to build.
> > > >
> > > > 1) I ran it with MAKE_JOBS=1 to get cleaner logging, and that resulted
> > > > in:
> > > >
> > > >   gmake[3]: Entering directory '/tank0/ztmp/work-xen/www/firefox102/work/build/toolkit/library/rust'
> > > >   toolkit/library/rust/force-cargo-library-build
> > > >   /usr/pkg/bin/cargo rustc  --release --frozen --manifest-path /tank0/ztmp/work-xen/www/firefox102/work/firefox-102.15.0/toolkit/library/rust/Cargo.toml -j1 -j1 --lib --target=x86_64-unknown-netbsd --features 'moz_places webrtc glean_with_gecko glean_disable_upload with_dbus' --  -Clto=thin
> > > >   error: the argument '--jobs <N>' cannot be used multiple times
> > > >
> > > > which I recognize from previous situations.   But that's easy to avoid.
> > > >
> > > > 2) I'm getting a rust error, which I suspect is due to rust.  I had
> > > > built firefox102-102.15.0 on September 19, and installed rust-bin-1.72.1
> > > > yesterday.
> > > >
> > > > gmake[3]: Entering directory '/tank0/ztmp/work-xen/www/firefox102/work/build/security/rlbox'
> > > > ../../dist/host/bin/wasm2c -o rlbox.wasm.c rlbox.wasm
> > > > 01bd146: error: unexpected opcode: 0xfc 0xa

FWIW I just finished a build of firefox102. It failed as above, but I
persisted and patched (using editors/bvi) rlbox.wasm, replacing the
two bytes with zeros. I had to do this a few more times (I ran the
wasm2c command above until it didn't give more locations with
unexpected opcodes - there were a few varieties to the above). The
resulting package appears to be working well and I can run Oshape
quite reasonably on that box.

Obviously, I don't know anything about how this particular file gets
created and why it failes so, just mentioning it in case somebody
needs WebGL (I still can't get the latest Firefox 118-whatever to do
it, despite the recent suggestions elsewhere on the list, hopefully
119 will get it back...).

 Chavdar

> > > >
> > > >
> > > > Does firefox102 build for others?
> > >
> > > I think that is https://bugzilla.mozilla.org/show_bug.cgi?id=1773200#c4
> > >
> > > Looks like a workaround is
> > >
> > > https://phabricator.services.mozilla.com/rMOZILLACENTRALd190451aa436ed6704b3f73bb91ddd71f6c48953
> > >
> > > (testing a local build now :)
> >
> > Unfortunately that patch to set BULK_MEMORY_SOURCES= does not appear
> > to help. I've also tried blindly copying ./third_party/wasm2c and/or
> > ./config/external/wasm2c_sandbox_compiler from firefox115 into
> > firefox102 without luck.
> >
> > I think if the build could be poked into adding -mno-bulk-memory to
> > clang at the right point it Should Just Work, but there are... layers
> > in the firefox build.
> >
> > Alternatively it might be possible to patch firefox102 to use the
> > wasm2c from devel/wabt rather than its shipped version. I'm going to
> > try a quick hack to run the build until it fails and then try
> > replacing the built wasm2c with a symlink to /usr/pkg/bin/wasm2c to
> > see if that approach might be worth trying
>
> OK, swapping in work/build/dist/host/bin/wasm2c as a symlink to
> /usr/pkg/bin/wasm2c (and touching /usr/pkg/bin/wasm2c so it was recent
> enough), then patching out the include to alloca.h in
> work/build/dist/system_wrappers/alloca.h gets past wasm2c but then
> chokes in ~endless
>
>   rlbox.wasm.c:503227:155: error: request for member 'data' in
> something not a structure or union
>
> ... so more understanding would be needed to continue with that approach :-p
>
>
> I'm going to try patching
>   taskcluster/scripts/misc/build-compiler-rt-wasi.sh
> and
>   taskcluster/scripts/misc/build-sysroot-wasi.sh
> to start a shell (as a convenient way to stop the build at that
> point), then poke around to see if I can find a place to add
> -mno-bulk-memory (everything is happening to generated files in
> generated directories at that point).
>
> David



-- 
----