Releasing wasi-sdk-31

[alexcrichton]

Similar to #587 I'd like to open an issue ahead of time about wasi-sdk-31. The current changelog includes:

• Source-level support for C++ exceptions (no current plans yet for continuous binary artifacts, see Support for C++ exceptions #565 for more info)
• Update to LLVM 22.1.0
• Source-level support for wasip3 as a target (no current plans for continuous binary artifacts, see WASIp3, threading ABI changes, LLVM releases, and schedules #589 for more info)
• Build libclang.so as part of the sysroot
• Build LLDB as part of the sysroot
• Clang's default target is now wasm32-wasip1 instead of wasm32-wasi

The changelog for wasi-libc includes:

• A number of fixes for networking in WASIp2 - don't mark just-connected socket ready-to-read in poll(2) wasi-libc#732, support non-blocking wasip2 sockets in read and write wasi-libc#734, only signal read (not write) readiness for listening sockets wasi-libc#737, report read readiness accurately for freshly bound UDP sockets wasi-libc#740, implement F_{GET,SET}FL for fcntl for sockets wasi-libc#742
• Work towards a more complete wasip3 target implementation, but it's not fully done yet.

---

The main headline feature of this release, in my mind, is LLVM 22.1.0. That fixes issues like #595 and is an update over the prior LLVM 21.x.0 version. That's also why I wanted to get this released after the wasi-sdk-30 release so soon, too.

As with prior releases, wanted to open this for comments/thoughts if anyone else has objections or other things they'd like to see included.

[alexcrichton]

Published

cc @cfallin, this is the first release with lldb

[cfallin]

cc @cfallin, this is the first release with lldb

Thanks very much!

[cfallin]

@alexcrichton it looks like there's a problem with libedit as a shared-library dependency on macOS/aarch64:

% /opt/wasi-sdk/bin/lldb
dyld[54331]: Library not loaded: /Users/runner/work/wasi-sdk/wasi-sdk/build/toolchain/install/lib/libedit.0.dylib
  Referenced from: <D8933E5A-E7F6-3964-8775-BEEBB9706048> /opt/wasi-sdk-31.0-arm64-macos/bin/lldb
  Reason: tried: '/Users/runner/work/wasi-sdk/wasi-sdk/build/toolchain/install/lib/libedit.0.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Users/runner/work/wasi-sdk/wasi-sdk/build/toolchain/install/lib/libedit.0.dylib' (no such file), '/Users/runner/work/wasi-sdk/wasi-sdk/build/toolchain/install/lib/libedit.0.dylib' (no such file)
zsh: abort      /opt/wasi-sdk/bin/lldb

The Linux packages don't show libedit.so in the ldd output so it must be statically linked on Linux; maybe it's dynamically linked by default on macOS (and we don't ship the dylib)?

[alexcrichton]

Oh dear...

To confirm, I'm seeing libedit.so and libedit.dylib everywhere. I've tested things on Linux (and so does CI) and it's all working, so Linux at least is expected to work. I didn't manually test on macOS (and neither does CI), and I can reproduce the problem you're seeing.

I think this is definitely a problem with the -install_name or w/e it is on macOS, but otherwise I think all the artifacts are there

[cfallin]

Yep, and to copy some info over from DMs: Alex suggested to try

$ DYLD_LIBRARY_PATH=`pwd`/lib bin/lldb

and that works locally for me. I guess I'll want to find a workaround to avoid the need for the environment variable though (via whatever linker options)...

[alexcrichton]

Attempting to fix that in #609, and if it works I'll tag wasi-sdk-32 shortly after.

[alexcrichton]

@cfallin can you test and confirm https://github.com/WebAssembly/wasi-sdk/releases/tag/wasi-sdk-32 works?

[cfallin]

@alexcrichton yep, that lldb build works great for me on macOS/aarch64. Thanks again!