Re: CVS commit: pkgsrc/www/firefox

[Havard Eidnes <he%NetBSD.org@localhost>]

Hi,

I got a comment that the previous message may not have been
entirely clear.  Let me try to explain.

The rust package can be built with two variants on NetBSD/i386:
configured for i586 (pentium) or for i686 (pentium4 and newer).
On i586, rust depends on mk/atomic64.mk to get 8-byte atomics
into play, needed by llvm, which may be integral to rust.

If CFLAGS doesn't already contain an -march= specification,
mk/atomic64.mk will add -march=i586.

It seems that with firefox 101, firefox now needs to be built
with -msse2 on our i386 port; at least in my case I got the
"target specific option mismatch" build error (that was while not
specifying anything regarding -march= or -msse2 in the firefox
Makefile, so atomic64.mk added -march=i586).

It also appears that the firefox build system checks to see if
the -march specified in CFLAGS matches the rust variant used to
build firefox.  So ... the code as it stands now disallows
building firefox using the i586 rust variant while also
specifying -march=i686 in CFLAGS.

I have succeeded building firefox 101 by using an i686-
configured rust 1.61.0, and by adding

CFLAGS+=        -march=i686 -msse2 -mtune=generic -mstackrealign

to the firefox Makefile.  I do not know if all of these are
required.  With this added, the build succeeded without errors in my
case.

I have not yet tested building firefox 101 by using the
i586-configured rust 1.61.0, and by adding

CFLAGS+=        -march=i586 -msse2 -mtune=generic -mstackrealign

but that is next on my plate.  Even though no CPU exists which only
does i586 but also has sse2, the theory is that the firefox build
system might allow the use of the i586-configured rust in this case,
but the resulting code will obviously only be runnable on >=i686 due
to -msse2.  We'll see what gcc (7 in this case, on 9.2) and the
firefox build system thinks about that.

Failing that, it could be argued that the firefox build system's
insistence on equal rust variant and derived host might be
loosened...

The rust we're currently shipping for NetBSD/i386 is the i586
variant, so that it may be used on e.g. AMD Geode chips.


BTW, I am currently trying a bulid with

MAKE_ENV+=     RUSTFLAGS="-C opt-level=1 -C codegen-units=1"

commented out.  I experienced one "abort" by rustc, but
restarting the build appears to have overcome that problem spot.
The backtrace I got was

Core was generated by `rustc'.
Program terminated with signal SIGABRT, Aborted.
#0  0xa45568f7 in _lwp_kill () from /usr/lib/libc.so.12
[Current thread is 1 (process 6)]
(gdb) where
#0  0xa45568f7 in _lwp_kill () from /usr/lib/libc.so.12
#1  0xa4556811 in raise (s=s@entry=6) at /usr/src/lib/libc/gen/raise.c:48
#2  0xa4555e70 in abort () at /usr/src/lib/libc/stdlib/abort.c:74
#3  0xa46509a2 in std::sys::unix::abort_internal ()
   from /usr/pkg/lib/libstd-d5e7b15a9b81c162.so
#4  0xa464797f in __rust_foreign_exception ()
   from /usr/pkg/lib/libstd-d5e7b15a9b81c162.so
#5  0xa467d0aa in __rust_panic_cleanup ()
   from /usr/pkg/lib/libstd-d5e7b15a9b81c162.so
#6  0xa4618c90 in std::panicking::try::cleanup ()
   from /usr/pkg/lib/libstd-d5e7b15a9b81c162.so
#7  0xa5133056 in _RNSNvYNCINvMNtCs2fsWnCEmWLs_3std6threadNtBa_7Builder16spawn_unchecked_NCINvXs0_Cs8iVpA9pE5Ri_18rustc_codegen_llvmNtB1f_18LlvmCodegenBackendNtNtNtCsccTtJdT3LS4_17rustc_codegen_ssa6traits7backend19ExtraBackendMethods18spawn_named_threadNCINvNtNtB2j_4back5write10spawn_workB1N_E0uE0uEs_0INtNtNtCs1vwdbJ0AxsW_4core3ops8function6FnOnceuE9call_once6vtableB1f_ ()
   from /usr/pkg/lib/librustc_driver-9e70acb8d6695e16.so
#8  0xa462eae9 in std::sys::unix::thread::Thread::new::thread_start ()
   from /usr/pkg/lib/libstd-d5e7b15a9b81c162.so
#9  0xa42c5553 in pthread__create_tramp (cookie=0x22a14000)
    at /usr/src/lib/libpthread/pthread.c:592
#10 0xa446b4b0 in __mknod50 () from /usr/lib/libc.so.12
#11 0x22a14000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) 

This might look like an llvm-internal thing which triggered the
abort.

Just FYI, the host I'm building firefox on is running NetBSD/i386 9.2
and is an IBM x3550 with 8GB memory installed, using the GENERIC_PAE
kernel, and it has a total of 6GB swap configured, and I'm doing the
build with MAKE_JOBS set to 3.


Best regards,

- Håvard