Re: No more firefox for i386?

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

>>> Will try with 1.82.0 next, and if that doesn't work, it doesn't
>>> look too hopeful.
>>
>> Some good news at last: rust 1.82.0 built firefox 138.0.4
>> successfully and natively on NetBSD/i386 10.0, and the result
>> runs and appears to work as one could expect.
>
> Retried this combination with rust-bin 1.84.0, and that fails
> with ENOMEM in the all too familiar manner.
>
> Sadly, it seems that I've lapsed, and we don't have a rust-bin
> 1.83.0 package in our archive, so I've not tried that one.

I've been trying a different angle at this problem.

I've tried with rust 1.88.0 (from pkgsrc-wip) both with the
internal LLVM 20 and with a pkgsrc-provided LLVM 19.

The initial attempt at building typically ends with

memory allocation of 70954688 bytes failed
   Compiling cert_storage v0.0.1 (/usr/pkgsrc/www/firefox/work/firefox-138.0.4/security/manager/ssl/cert_storage)
warning: `style` (lib) generated 730 warnings (run `cargo fix --lib -p style` to apply 729 suggestions)
error: could not compile `style` (lib); 730 warnings emitted

However...  If I try to re-build from that point (just issue a
new "make replace" from the www/firefox package directory), there
appears to be a non-zero chance that the build succeeds(!)  I
have a sample size of 2 (yes, that's almost "anecdotal"), and
both succeeded.

I submitted an issue to the rust github repository, you can see
it at

https://github.com/rust-lang/rust/issues/143904

One question I got there was whether the build is being done with
LTO (link-time optimization) turned on, as that can cause both
significant bloat in the rust compiler as well as (I have
understood) significantly increased build time.

However, I tried adding

.if !empty{MACHINE_PLATFORM:MNetBSD-*-i386}
# As opposed to -enable-lto=thin
CONFIGURE_ARGS+=        --disable-lto
# For debugging:
MAKE_ENV+=              RUSTC_BACKTRACE=1
.endif

to options.mk, but despite this I observe rustc processes in
top's thread display ("t") with "lto" in their names, so
evidently this does *not* disable LTO (yet, the firefox configure
script appears to have accepted this argument, go figure).

Secondly, I got to thinking what might vary between subsequent
build attempts, and one thing is "of course" ASLR (address-space
layout randomization).  That obviously costs some virtual space
(how much?), so what about trying a build with that turned off?

So I adjusted the following sysctl variables (both were 1
earlier):

security.pax.aslr.enabled = 0
security.pax.aslr.global = 0

and by the looks of it, this build attempt will succeed:

$ ls -l list.6[1-5]
-rw-r--r--  1 he  wsrc   2800661 Jul 14 10:06 list.61
-rw-r--r--  1 he  wsrc  14539909 Jul 14 15:33 list.62
-rw-r--r--  1 he  wsrc   2800661 Jul 14 20:47 list.63
-rw-r--r--  1 he  wsrc  14553603 Jul 15 01:28 list.64
-rw-r--r--  1 he  wsrc   9438731 Jul 15 13:23 list.65
$

61+62 is the first "build + rebuild" build logs.
63+64 is the second "build + rebuild" build logs.

list.65 is the current build log, so the spot where the build
earlier bombed out with memory allocation error has long since
passed, but obviously it's not completed yet.

Apparently a complete build of firefox takes around 6h wallclock
time on this host, with a parallellism of 3.  This build started
09:22 this morning, so there's a couple of more hours to go.

However, aslr is a global option, so ... hm.  Isn't it also a
flag on the rustc executable, ref. paxctl?  Turning that off for
the rustc executable might be the next test.  The status now &
some testing:

$ paxctl /usr/pkg/bin/rustc
No PaX flags.
$
$ cp /usr/pkg/bin/rustc /var/tmp
$ cd /var/tmp
$ paxctl rustc
No PaX flags.
$ paxctl +a rustc
$ paxctl rustc
PaX flags:
  a: ASLR, explicit disable
$ file rustc
rustc: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /usr/libexec/ld.elf_so, for NetBSD 10.0, PaX: -ASLR, with debug_info, not stripped
$

More along that axis later.

Yes, this is probably just balancing right on the edge of virtual
address space exhaustion, and there's no telling when we next
fall over that edge.

Is anyone going to try to build thunderbird on i386? :)


Regards,

- Havard