Package: clang-14 Version: 1:14.0.6-2 Severity: normal Attempting to build a trivial "hello world" program for the wasm32-unknown-wasi target with: clang -v -target wasm32-linux-wasi -o test.wasm test.c
...results in a cc1 command-line that includes: -internal-isystem /include/wasm32-wasi -internal-isystem /include ...naturally followed by: ignoring nonexistent directory "/include/wasm32-wasi" ignoring nonexistent directory "/include" If one were to pass "-I/usr/include/wasm32-wasi" to work around this, it becomes apparent that a similar situation is the case for -L: wasm-ld-14 ... -L/lib/wasm32-wasi /lib/wasm32-wasi/crt1-command.o ... Looking at the source, sysroot is prepended on these paths, and seems to be implied to be always expected. Presumably this originated in a world where folks had the WASI SDK (and wasi-libc) installed in /opt. In Debian, the wasi-libc package (the libc for this platform) uses the /usr/include/wasm32-wasi and /usr/lib/wasm32-wasi paths. Apparently passing --with-sysroot=/usr works around this issue, pointing clang to the right paths in Debian. However, it would be ideal if that indirection was not necessary, and clang did the right thing out of the box, instead of attempting to access nonexisting unprefixed paths like /include/. An example, *untested* kinda hacky fix for this could take the form of adding this to clang/lib/Driver/ToolChains/WebAssembly.cpp: std::string WASI::computeSysRoot() const { if (!getDriver().SysRoot.empty()) return getDriver().SysRoot; std::string Path = "/usr"; if (getVFS().exists(Path)) return Path; return std::string(); } Also see #1014567 which describes my confusion upon encountering wasi-libc. It can be resolved if this bug is accepted, or repurposed to be a documentation wishlist bug. Finally, note that even with the fix described in this bug, compilations to the wasm32-linux-wasi target will not work until #1010932 (availability of compiler-rt for wasm32) is resolved. Regards, Faidon