|Reported by:||Owned by:|
The second available candidate build for 78.0esr is now available, so before the release next week I'm creating this to document some items of interest.
- 78.0esr is different from 78.0 in three ways:
· the version is labelled as 78.0esr instead of 78.0
· extensions do not need to be signed by the trusted root (I guess that is for organizations which create their own extensions)
· some nightly options for enabling webrender have been removed, making the tarball slightly smaller.
The nightly options are o convcern, esr cannot be nightly.
Allowing unsigned extensions for the ordinary esr user seems like a bad idea in terms of security: "Why don't you download and install this handy extension of mine ?".
Fortunately, it can be fixed with a sed to revert that change:
sed -i -e 's/Disable/Enable/' \ -e '/^MOZ_REQUIRE_SIGNING/s/0/1/' \ build/mozconfig.common
As (mostly) noted in the wiki, the accepted build options have changed:
· --disable-webm is no longer accepted, but webm should continue to be recommended because there is a shipped version.
· --disable-startup-noification is no longer accepted, therefore startup-notification becomes required.
· --enable-system-sqlite is no-longer accepted. I guess that after the issue a few moths ago where they were found to be using an internal feature they've decided to keep their own version which works for them. Unlike the situation several year ago where mixing shipped sqlite in firefox and system sqlite in other things apparently caused problems, so far this seems to be ok.
· --with-system-bz2 is no-longer accepted, I assume they've got rid of bz2.
With the first esr candidate I've looked at the difference between using mozilla's preferred clang, clang++ (preferred as in "one toolchain for all platforms") and gcc, g++.
On my machine, the build sizes are consistent for each toolchain across several builds. It is not needed to specify the full set of 'CC=clang CXX=clang++ AR=llvm-ar NM=llvm-nm RANLIB=llvm-ranlib' to use clang and clang++ although specifying all does give a slightly smaller and slower build than just using clang and clang++. In either case, the default bfd linker is used.
Traditionally, llvm and therefore clang has been slow to add security hardening. I think that the available hardening flags for x86 (although not for aarch64 and probably not for 32-bit ARM) are now probably the same as in gcc - no idea if they work as well as in gcc, but they seem to be accepted.
So, I tested a series of builds with both gcc, g++ and clang, lang++.
Using gcc, the build and install total 4.9 GB (184 MB installed), using clang the build and install is 77MB smaller at 4.8GB (180 MB installed). I confirmed that neither is using LTO (except that rust code passes -Clto in two places) - that would probably need a PGO build (see Arch) which will take a lot longer.
So, using clang might be a possibility. But repeated tests indicate it is a slower build. Since a BLFS user should (now) expect to update firefox on a 4-weekly cycle, the extra time to build with clang doesn't seem beneficial (and I cannot see that a marginally smaller install will start up noticeably quicker.
Anyway, I did 5 builds of each, with SBU rounded to next unit, and also rounded to three decimals, then averaged.
gcc, rounded to whole SBU 31 33 32 31 32 avg 31.6 and to three decimals 30.98 32.657 31.507 31.418 31.502 avg 31.613
clang, to whole SBU 35 34 33 32 34 avg 33.6 and to three decimals 35.35 33.597 33.326 31.625 33.763 avg 33.532
So the average is 32 SBU with gcc, and 34 SBU with clang.
Yes, this is about 50% slower than firefox-68.9.0.
The webrender items in the diff from 78.0 caused me to look at that: it is still opt-in, but my preliminary tests suggest it can be worthwhile. I've got to do some more tests on a low-end intel (on my haswell i7 it uses typically 20% of 1 cpu, instead of 4 to 5% on ATI R600 and amdgpu), but I epect to add details to the configuration section.