Le Thu, Jul 23, 2026 at 12:17:00PM +0100, Leah Rowe a écrit : > > see other reply: > > check the firefox port. i do changes pretty conservatively, only adapting > firefox port changes, plus adaptations for librewolf-specific changes e.g. > policy changes, mozconfig (referencing upstream). > > the firefox port does that CPU thread check and caps the limits based on the > architecture it's being built on. openbsd doesn't cross compile, it always > compiles on each host, and some of those architectures require limiting the > number of threads due to memory usage, because the firefox port uses a lot > of memory when compiling it.
just to correct things here: - that's not 'the port uses a lot of memory when compiling it' (albeit that's also true) nor related to crosscompile - its 'lld takes gobs of resources when linking libxul.so' - there was an ugly 'NCPU !!= sysctl -n hw.ncpuonline' construct to get the amount of cores available. ugly because its evaluated/executed each time the makefile is read. - depending on the value, it used it or capped it to 5 - lld upstream defaults to use all available cores, which was producing bad resource usage with many cores (eg >= 16) - cf https://marc.info/?t=173106489200001&r=1&w=2 - our lld gained a local modification that caps it to 4. cf https://github.com/openbsd/src/commit/e41c3d4bccf9b5cf584f1453e0a028fd066cd926 - i initially thought the capping happened only *IFF* -Wl,--threads was used, but rereading the above commit, it doesnt seem to be the case. I'll recheck in my next build. - so in the end i think the -Wl,--threads bit should be dropped from LDFLAGS and come back to --ld-path=${WRKDIR}/bin/ld hope it helps clarifying things.. i'll commit the final diff for lw 153.0-3 when its been properly tested. Landry
