www/firefox: update/rework WASI logic

[vishwin]

Summary

Use newer WASI stack, aligned with bundled LLVM in rust, which allows for working LTO again. Bump PORTREVISION to rebuild under this stack.

Rework WASI logic by explicitly specifying version variables, taking them out of the default-versions/LTO option logic. Without this, ${LLVM_VERSION} is undefined when LLVM_DEFAULT is set in make.conf resulting in dependency not found.

Test Plan

Results in functional software regardless of LTO option or LLVM_DEFAULT.

[cmt]

The whole LLVM_DEFAULT logic in bsd.gecko.mk should just go away, and LTO as well perhaps. Less options, less problems. (Also, the build-wasi-with-llvm stuff is overdue (but I only half-finished it because life happened), as it would be much easier to alwys have the version matching llvm immediately).
Also, please wait with this as I expect firefox 101 next week.

[vishwin]

Nothing goes in until we definitively figure things out. WASI-with-LLVM sounds good.

I'd prefer keeping LTO as an option, which doesn't have to be a default. There are at least a few folks who want to keep rolling with LTO despite the build-time drawbacks, who instinctively know to keep LLVM versions synchronised at all times.

[fluffy]

[tcberner]

Mk/bsd.gecko.mk

100

^why change it to 14 in one go?

This looks like two changes

1. make the variables available in general
2. bump to 14

[fluffy]

Mk/bsd.gecko.mk

100

14 because of wasi-libcxx which is also bumped to latest llvm sources, I assume :)

[2khramtsov_gmail.com]

In D35289#799860, @cmt wrote:

The whole LLVM_DEFAULT logic in bsd.gecko.mk should just go away, and LTO as well perhaps. Less options, less problems.

Inflexible defaults may not meet user requirements, and one of the goals of the FreeBSD port collection is to provide software as close to upstream as possible.
Ports should provide mechanism to build software for FreeBSD, and policy is decided by user and its ranges are set by upstream, e.g.:
https://github.com/mozilla/gecko-dev/blob/2398ab33adcea896838b3da678ff6480dbb98b9a/python/mozbuild/mozbuild/test/configure/test_toolchain_configure.py#L494

Limiting user's policy because of a maintainer's wish to test every policy variation (does it even scale?) is a regression from upstream and an artificial limitation of possibilities (e.g. I need this together with D32654).
Besides, maintainers aren't obligated to QA non-default versions (e.g. Python); what is normally maintained is the default set on project's package builders.

Dropping LLVM_DEFAULT will not bother me as I will "git rebase" as I usual, but can worsen experience for new users or those who can't maintain local changes.

[2khramtsov_gmail.com]

llvm=14 works here without reverts as of ports 8367c2b68a92 + latest revisions in the stack + devel/wasi-libcxx license path fix.

llvm=13 needs additional ports makefile fix because www/firefox BUILD_DEPENDS+= ${LOCALBASE}/llvm${WASI_LLVM_DEFAULT}/lib/clang/${WASI_LLVM_VERSION}/lib/wasi/libclang_rt.builtins-wasm32.a:devel/wasi-compiler-rt${WASI_LLVM_DEFAULT}
always pushes devel/wasi-compiler-rt14 in together with selected LLVM version, so version mismatch happens:

[...]
===>   firefox-103.0,2 depends on file: /usr/local/llvm14/lib/clang/14.0.6/lib/wasi/libclang_rt.builtins-wasm32.a - not found
===>   Installing existing package /packages/All/wasi-compiler-rt14-14.0.6.pkg
[ei-ei-job-01] Installing wasi-compiler-rt14-14.0.6...
[ei-ei-job-01] Extracting wasi-compiler-rt14-14.0.6: .... done
===>   firefox-103.0,2 depends on file: /usr/local/llvm14/lib/clang/14.0.6/lib/wasi/libclang_rt.builtins-wasm32.a - found
===>   Returning to build of firefox-103.0,2
===>   firefox-103.0,2 depends on package: llvm13>0 - not found
===>   Installing existing package /packages/All/llvm13-13.0.1_3.pkg
[...]
/usr/local/bin/clang++13 -std=gnu++17 --target=wasm32-wasi --sysroot=/usr/local/share/wasi-sysroot -o rlbox.wasm -Wl,--export-all -Wl,--stack-first -Wl,-z,stack-size=262144 -Wl,--no-entry -Wl,--growable-table ogg_alloc.wasm ogg_bitwise.wasm ogg_framing.wasm xmlparse.wasm xmlrole.wasm xmltok.wasm wasm2c_sandbox_wrapper.wasm mozHunspellRLBoxSandbox.wasm affentry.wasm affixmgr.wasm csutil.wasm hashmgr.wasm hunspell.wasm phonet.wasm replist.wasm suggestmgr.wasm GraphiteExtra.wasm CmapCache.wasm Code.wasm Collider.wasm Decompressor.wasm Face.wasm FeatureMap.wasm FileFace.wasm Font.wasm GlyphCache.wasm GlyphFace.wasm Intervals.wasm Justifier.wasm NameTable.wasm Pass.wasm Position.wasm Segment.wasm Silf.wasm Slot.wasm Sparse.wasm TtfUtil.wasm UtfCodec.wasm call_machine.wasm gr_char_info.wasm gr_face.wasm gr_features.wasm gr_font.wasm gr_logging.wasm gr_segment.wasm gr_slot.wasm json.wasm RLBoxWOFF2Sandbox.wasm table_tags.wasm variable_length.wasm woff2_common.wasm woff2_dec.wasm woff2_out.wasm -lwasi-emulated-process-clocks
wasm-ld: error: cannot open /usr/local/llvm13/lib/clang/13.0.1/lib/wasi/libclang_rt.builtins-wasm32.a: No such file or directory
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)
[...]

llvm=13 LTO=on (with lang/rust LLVM_PORT=on) build passes after local test change to pull devel/wasi-compiler-rt13 in.

Maybe update www/firefox/Makefile and/or Mk/bsd.gecko.mk to pull in the correct wasi-compiler-rt based on selected LLVM version?
llvm=13 may be desirable to reduce LLVM proliferation when GL_DEFAULT=mesa-libs (default).

[2khramtsov_gmail.com]

As LLVM moved to bi-weekly bugfixes (point) releases [1] maybe consider other change in Mk/bsd.gecko.mk, or devel/llvm*, or start cooperating with LLVM maintainer(s) to also bump WASI_LLVM_VERSION on a LLVM point release?
14.0.6 seems to be the last point release in 14 series, so there is enough time to figure out design improvement.

[1]: https://discourse.llvm.org/t/llvm-14-0-2-release/62065

[vishwin]

Superseded by D40098