Re: git: 980444a82fbd - main - www/firefox: update to 100.0 (rc2)

On Tue, 03 May 2022 18:53:23 +0200
Jan Beich <jbeich@FreeBSD.org> wrote:

> Emmanuel Vadot <manu@bidouilliste.com> writes:
> 
> > On Tue, 3 May 2022 17:45:14 +0200
> > Christoph Moench-Tegeder <cmt@burggraben.net> wrote:
> >
> >> ## Joseph Mingrone (jrm@FreeBSD.org):
> >> 
> >> > Turning LTO off fixed the problem here.
> >> 
> >> I just found out that turning LTO on breaks firefox for me, so that
> >> settles that. I'll push that soon.
> >
> > That's good for now thanks but what about the futur ?
> > Should we allow to have LTO turn on on port that uses both LLVM and
> > Rust ? Because otherwise it will happen again when a new rust version
> > if released and the llvm version isn't the same.
> 
> - Known since https://cgit.freebsd.org/ports/commit/?id=b1c90afe23f9
> - Adhered previously in https://cgit.freebsd.org/ports/commit/?id=124261fa7deb
> - Complicated by wasi-compiler-rt* split from llvm* packages
> 
> Mozilla recommends its own Firefox builds due to LTO + PGO. FreeBSD is a
> Tier3 (aka "patches welcome" and no CI), so disabling LTO will reduce
> performance with no fallback binaries. Rebuilding Firefox locally isn't
> a good proposition due to long build time (more with LTO), high memory
> requirement (more with LTO), frequent updates to firefox and many of its
> dependencies (harfbuzz, nss, ffmpeg, etc).
> 
> I've enabled LTO by default a year ago to prevent dilapidation. Back then
> when LTO was exposed there were numerious bug reports about broken build.

 I'm glad that it's known for a year and that no one tried to make a
policy that will prevent this from even happening.
 What's the perf impact on disabling LTO on Firefox ?

-- 
Emmanuel Vadot <manu@bidouilliste.com> <manu@FreeBSD.org>