Page MenuHomeFreeBSD

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

Authored by vishwin on May 14 2023, 10:07 PM.
Tags
None
Referenced Files
F106031109: D40098.diff
Tue, Dec 24, 4:33 AM
Unknown Object (File)
Sat, Dec 14, 11:48 AM
Unknown Object (File)
Thu, Dec 5, 12:32 PM
Unknown Object (File)
Mon, Dec 2, 9:41 PM
Unknown Object (File)
Fri, Nov 29, 7:15 PM
Unknown Object (File)
Fri, Nov 29, 8:09 AM
Unknown Object (File)
Fri, Nov 29, 8:09 AM
Unknown Object (File)
Fri, Nov 29, 8:09 AM
Tokens
"Love" token, awarded by osa.

Details

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.

Diff Detail

Repository
R11 FreeBSD ports repository
Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 54505
Build 51394: arc lint + arc unit

Event Timeline

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

12 is the minimum supported LLVM version.

  • www/librewolf: adjust WASI dependencies

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).

  • 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 retitled this revision from wasi: update libc to sdk-19 and modularise LLVM bits to wasi: update libc to sdk-20 and modularise LLVM bits.Jun 18 2023, 3:29 AM
  • MOVED: remove stray conflict mark
  • gecko-esr: limit to LLVM 15 due to old proc-macro2 crate
  • devel/wasi-{compiler-rt,libcxx}16: sync with devel/llvm16 16.0.6

update/add LLVM 17 support/pieces

arrowd added inline comments.
devel/wasi-libc/Makefile
33

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

  • devel/wasi-{compiler-rt,libcxx}17: sync to 17.0.3
  • Revert "gecko-esr: limit to LLVM 15 due to old proc-macro2 crate"
  • devel/wasi-libc: remove extra ${CC} after USES=llvm default export

remove stray conflict artefact

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
7809–7810

Is there any sense in hooking this up?

devel/wasi-libcxx17/Makefile
3
eric_camachat.org added inline comments.
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.

devel/Makefile
7809–7810

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?

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

Yes, I have CPU flags in make.conf

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

another stray conflict mark

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