wasi: update libc to sdk-20 and modularise LLVM bits

[vishwin]

Summary

Update wasi-libc to sdk-19, with patch to null out bulk memory opcodes that the mozilla-{release,esr} codebase fails to build with.

wasi-libcxx and wasi-compiler-rt now meta ports; the build process is the same for each LLVM version so child ports are minimal. Flavours don't work here due to differing LLVM versions between them. Note that LLVM 16 changed the directory hierarchy to major version only, so cannot use exact file references for the wasi-compiler-rt dependency line any longer.

Since all supported LLVM versions are made available at once, remove restriction in bsd.gecko.mk. While here switch to USES=llvm throughout, max version limited to 15 for now (see below).

Test Plan

Dogfooded with both LLVM 14 and 15. 16 made available but gecko-ESR-based ports don't build because outdated proc-macro2 crate, and runtime crashes being investigated on mozilla-release (www/firefox). Once mozilla-release is fixed, LLVM 15 max restriction can go away but need to remain in ESR only until crate(s) are updated.

[vishwin]

• MOVED: add forgotten devel/wasi-compiler-rt11

12 is the minimum supported LLVM version.

[vishwin]

• www/librewolf: adjust WASI dependencies

[brooks]

This feels like flavors might make sense instead of the shared pseudo ports, but seems fine as is. I might give the pseudo ports a nonstandard directory name to highlight that they are aren't really ports (e.g., devel/_wasi-libcxx or devel/.wasi-libcxx).

[vishwin]

• devel/wasi-libc: update to wasi-sdk-20
• devel/wasi-{compiler-rt,libcxx}16: sync with devel/llvm16
• devel/wasi-libcxx: fix LICENSE_FILE location
• bsd.gecko.mk: remove LLVM version restriction

Note that bulk memory opcodes continue to need null out until gecko 115/ESR is released, see Mozilla bug 1831980.

[vishwin]

• MOVED: remove stray conflict mark

[vishwin]

• gecko-esr: limit to LLVM 15 due to old proc-macro2 crate

[vishwin]

• devel/wasi-{compiler-rt,libcxx}16: sync with devel/llvm16 16.0.6

[vishwin]

bad arc bad

[vishwin]

update/add LLVM 17 support/pieces

[arrowd]

devel/wasi-libc/Makefile

33

This now is not needed anymore, I guess? USES=llvm exports CC/CXX by default unless noexport is specified.

[vishwin]

• devel/wasi-{compiler-rt,libcxx}17: sync to 17.0.3
• Revert "gecko-esr: limit to LLVM 15 due to old proc-macro2 crate"

[vishwin]

• devel/wasi-libc: remove extra ${CC} after USES=llvm default export

[vishwin]

remove stray conflict artefact

[brooks]

In general this seems fine. I do find myself wondering why it's necessary or useful to have the versioned packages conflict with each other by installing in share/wasi-sysroot instead of share/wasi-sysroot${LLVM_VERSION}.

devel/Makefile

7810–7811

Is there any sense in hooking this up?

devel/wasi-libcxx17/Makefile

3

[eric_camachat.org]

devel/wasi-compiler-rt/Makefile

32–33

For some reason, it also need WITHOUT_CPU_CFLAGS=yes on my machine.

devel/wasi-compiler-rt17/Makefile

3

devel/wasi-libcxx/Makefile

33–34

For some reason, it also need WITHOUT_CPU_CFLAGS=yes on my machine.

[vishwin]

devel/Makefile

7810–7811

Will probably get an earful about breaking INDEX otherwise?

devel/wasi-compiler-rt/Makefile

32–33

Do you have CPU flags set in your make.conf?

[vishwin]

• devel/wasi-{compiler-rt,libcxx}17: sync to 17.0.5

[vishwin]

phab...

[eric_camachat.org]

devel/wasi-compiler-rt/Makefile

32–33

Yes, I have CPU flags in make.conf

[vishwin]

• devel/wasi-{compiler-rt,libcxx}: add WITHOUT_CPU_CFLAGS
• devel/wasi-libc: remove BULK_MEMORY_SOURCES omission, all gecko now supports those opcodes

[vishwin]

another stray conflict mark

[vishwin]

• bsd.gecko.mk: add :noexport to USES=llvm, for any GCC cases

[vishwin]

Committed but the auto-close didn't work