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

Craig Leres wrote:
> On 5/3/22 05:23, Jan Beich wrote:
>  > Try rebuilding without LTO. rust-1.60 emits LLVM 14 bytecode that LLD
>  > from llvm13 may not understand. firefox cannot switch to llvm14 yet
>  > due to missing wasi-compiler-rt14. In the past firefox build usually
>  > broke due to LLVM mismatch, so such issues were easy to notice.
> 
> Forgive my lack of knowledge of rust/llvm but would it be possible for 
> the rust port (or binary) to expose the version of llvm bytecode it 
> outputs such that ports that use rust and llvm (and LTO) could detect 
> and error out at build time when they do not match? I looked at rustc 
> flags but don't see an obvious way to reveal the bytecode version. But 
> even just defining it by hand in the rust Makefile might solve this?
> 
Prior to LLVM 8.0, Rust's LLVM submodule tracked LLVM trunk at Rust 
release time. They've gotten better with tracking release branches 
rather than trunk, with the current Rust 1.60.0 tracking LLVM 14.0.0. 
[0] However, Rust does this via their own LLVM fork [1] not least due to 
Rust's own idiosyncrasies and the ability to cherry-pick fixes similar 
to what we do in base.

We had a PORT_LLVM option in lang/rust prior to [2], but that was 
removed in the pre-LLVM 8.0 cycles due to a cpu_features-like API in 
RustLLVM that Firefox and Thunderbird needed. There's been some 
development about "supporting" external LLVM code generators since then, 
culminating on our end as D32654. I'm thinking about giving it a whirl, 
but note that external LLVM code generators are not supported in the 
same vein like RustLLVM and thus should not become a default.

[0] 
https://github.com/rust-lang/llvm-project/blob/c8eccf626fb5bb851b2ade93af8851ca1523807f/llvm/CMakeLists.txt
[1] https://github.com/rust-lang/llvm-project
[2] https://svnweb.freebsd.org/changeset/ports/454983

-- 
Charlie Li
…nope, still don't have an exit line.