wasi-sdk-31 is broken (libncurses error)

[mh4ckt3mh4ckt1c4s]

Hello,

wasi-sdk-31 (and wasi-sdk-32 prerelease) is broken with the following error:

> ./wasi-sdk-31.0-x86_64-linux/bin/clang main.c
./wasi-sdk-31.0-x86_64-linux/bin/clang: error while loading shared libraries: libncurses.so.6: cannot open shared object file: No such file or directory

When using a basic main.c :

#include<stdio.h>
#include<stdlib.h>

int main() {
        puts("Hello from wasm\n");
        return 0;
}

Seems like the binaries were not linked correctly. It works fine with wasi-sdk-30. I was able to reproduce this bug on my ArchLinux machine, but also on a clean Debian container, and it seems like the official Docker release of wasi-sdk is broken too.

[alexcrichton]

Thanks! Can confirm, yeah. I'll try to get this fixed for wasi-sdk-32's official release. Dunno how that's gonna happen, but one can always hope that a solution will come out of the woodwork.

[mh4ckt3mh4ckt1c4s]

Do you have any idea where that could come from? If not I can try to look for the root cause.

[alexcrichton]

Oh it's coming from #596, notably libedit, and I'm trying to figure out if it's possible to use libedit without depending on ncurses

[sbc100]

Can we just add a extra documented dependency here? Seems like an ncurses dep is a pretty low bar.

[alexcrichton]

I wrote up a bit here too, but personally I'd perfer to avoid picking up deps unless they're necessary, and I'm not aware of the ncurses dep really buying much

[sbc100]

Why not instead drop the libedit dependnecy then? its seems like a bunch of extra complexity here. Or is it not optional?

[alexcrichton]

Good question yeah, and I've found that while libedit is indeed an optional dependency the CLI of LLDB is-more-or-less unusable when it's disabled. I've been trying to keep it enabled to keep the CLI useful-enough and it's been a game of whack-a-mole getting it enabled without causing other issues. It's a bit of a bummer that libLLVM.so itself depends on libedit.so so this is problematic even for just clang if you're not using lldb.

[sbc100]

I see... so libedit is providing real value but the transitive ncurses dependency is not providing much of anything?

I wonder if the upstream libedit folks would be interesting in this patch?

[alexcrichton]

I'm quite certain about the libedit part providing value, but I'll admit that I'm being handwavy about ncurses providing not much value (and wouldn't be certain about that). I basically ran ./bin/lldb and it looked similar before/after and I'd prefer to wait for feature requests like #612 before optional dependencies are enabled.

As for upstream, AFAIK the upstream is https://www.thrysoee.dk/editline/ which I wouldn't know how to send changes to and I also don't really have the energy personally to pursue it, I'd prefer to sort out the wasi-sdk use case and be able to move on

[sbc100]

Sorry, I wasn't tryng to give you more work to do. More like I'm wondering why this issue is something we need to hack like this give that others seem to be experiencing the same issues.

I wonder if most linux users just have ncurses installed already so don't run into this?

I'd also like to suggest that you don't need to spend too much of your time making the pre-built binaries work for all niche linux distros. niche linux distros are normally very well setup to build their own binaries. I don't think its unreasonable to push back against certain requests for long tail compat.

[alexcrichton]

Oh no worries, I think it's a reasonable question to ask! Personally I see wasi-sdk in a different position than Linux distributions for example since we're building one set of binaries that more-or-less needs to work in as many places as possible. If we were paskaging this in a Linux distribution, for example, I think it'd be fine to just add dependencies and call it a day, so to me that's why most linux users don't run into this -- packagers take care of dependencies and users don't really notice an extra dep or two.

I definitely dread dealing with build issues all day myself, and I am certainly no fan of handling them all... That being said I do think that the current ncurses dep crosses the line insofar as even the default docker images here don't work but additionally the binaries don't work in a stock ubuntu:24.04 container either.

Partly this is why I think it's good to build as few tools as possible here in wasi-sdk because it means the dependencies stay slim and it's just one problem to solve. LLDB is a much bigger dependency than I originally thought as it seems like it needs a whole array of upstream libraries to be usable unfortunately. In retrospect it might be too much to take on, but I'm hopeful that it's almost done at least

[alexcrichton]

I've published https://github.com/WebAssembly/wasi-sdk/releases/tag/wasi-sdk-32 with the fix for this