i will make the patch less invasive and more generalised later on.

the autovar zero init line that you asked about does exactly what it 
suggests. when compiling, the compiuler will detect if certain local 
variables are not initialised in C/C++ functions (initialising them to 
zero). this fixes a bunch of accidental bugs when the devs accidentally 
leave local variables uninitialised inside functions. i use this in my 
librewolf port as that is what librewolf upstream already adds.

not all of those build options are universally available in every 
codebase, so i'd still have to modify some of the individual ports, e.g. 
enable-stl-hardening isn't available in tor-browser or seamonkey, so 
would have to be added there.

i just imported librewolf's additions to other mozilla projects in 
openbsd. as for the --enable-rust-simd option, yeah the risk there is 
sometimes it's sensitive if rustc updates and you're stuck on an older 
mozilla codebase, so the issue is with ESR releases on projects

i'd probably leave --enable-rust-simd turned off by default on ESR projects.

PS: while i have you, because i forgot to ask the other day:

why is there a thunderbird package that only references ESR release? why 
not have e.g. mail/thunderbird-esr and mail/mozilla-thunderbird like 
with the firefox package, the latter referencing newer releases and the 
former only referencing ESR?


Am 05.09.26 um 09:39 schrieb Landry Breuil:
> Le Fri, Sep 04, 2026 at 04:39:48PM +0100, Leah Rowe a écrit :
>> your three dots are deserved, at the end there. it even occured to me while
>> writing, that openbsd very likely already implements all that stuff itself.
>>
>> if you want to omit --enable-hardening and --enable-stl-hardening, that's
>> fine. i just added them because i thought, yeah why not.
>>
>> really then the only flags that i can think of that openbsd might find
>> worthwhile on the ports are:
>>
>> --enable-rust-simd
> what does this bring, and what are the potential downsides ?
> incompatibilities with rust versions ? afaict that's a knob pushed on by
> default upstream, so why not. cf
> https://searchfox.org/firefox-main/source/build/mozconfig.rust#1 &
> https://searchfox.org/firefox-main/source/build/mozconfig.common#22,
> that might already by included by librewolf ? *shrug*
>
>> (the tests/crashreporter disablement are optional really)
> the crashreporter is already disabled by default:
> https://searchfox.org/firefox-main/source/toolkit/moz.configure#3455
>
> as for tests, really but no thanks, the tests are useful sometimes, at
> least to me, cf
> https://github.com/openbsd/ports/commit/804da332adc2853a47ea0943b2397b9d63e795d0
> &
> https://github.com/openbsd/ports/commit/4d03e87c26820c31d769694b30c9f4d3b977ec73
>
>> -ftrivial-auto-var-init=zero <-- this one, in the patch, might still be
>> desirable. not sure if openbsd does that in its compilers.
> i have no idea what this does. do you ? there are some references
> upstream, cf
> https://searchfox.org/firefox-main/source/build/moz.configure/toolchain.configure#2907
>
> generally speaking, i tend to avoid pushing knobs when i dunno what they
> do. and i avoid diverting from upstream for the sake of "we're special"
> because it can lead to self-inflicted harm later on.
>
> and as i already said, if things have to be factorized, that's in
> mozilla.port.mk. no point in duplicating the same lines in 4 or 5
> makefiles...

-- 
Company director, Minifree Ltd
Registered in England, No. 9361826 | VAT No. GB202190462
Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK

• OpenPGP_0x5C654067D383B1FF.asc (3K)